mikeorr / unipath Goto Github PK

Finish issues and pull requests in the legacy Bitbucket repository (https://bitbucket.org/sluggo/unipath/issues)

There is a small typo in test.py.
Should read temporary rather than temprorary.

Python 3.6 introduced PEP 519

Short summary in python 3.6 here: https://docs.python.org/3/whatsnew/3.6.html#pep-519-adding-a-file-system-path-protocol

import unipath
import pathlib

print(unipath.Path('a', 'b', pathlib.Path('c', 'd')))

Presently the above code would fail with TypeError: arguments must be str, unicode, list, int, long, or Path

If os.fspath is present it could be used to convert a path-like object into a string.

(unipath.Path could also be changed to implement __fspath__ but since str is already an ancestor class I'm not sure that what it would achieve)

Hi,

In the docs you mention real_path, but it doesn't work for me:

>>> p = Path('/run/media')    # it's a link on my machine
>>> p.real_path()
Traceback (most recent call last):
  File "<input>", line 1, in <module>
AttributeError: 'Path' object has no attribute 'real_path'

Thanks,

Laszlo

Can use from github clone version but cannot use from pip3 install unipath.

C:>pip3 freeze
Unipath==1.0

C:>python3
Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:15:05) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

from unipath import Path
Traceback (most recent call last):
File "", line 1, in
File "C:\Python34\lib\site-packages\unipath__init__.py", line 4, in
from unipath.abstractpath import AbstractPath
File "C:\Python34\lib\site-packages\unipath\abstractpath.py", line 11, in
_base = os.path.supports_unicode_filenames and unicode or str
NameError: name 'unicode' is not defined

My colleague using Linux is not getting this error, but on OSX running django-admin.py runserver or python manage.py shell causes the command line to throw out this name error - we used unipath in our settings module.

We're using Python 3 with virtual env with Unipath version 1.0. Any help would be super appreciated!

I find Path.rel_path_to() method to be quite confusing. Consider the following example:

In [27]: %paste
from unipath import Path
p1 = Path('/a/b')
p2 = Path('/a/b/c/d')
print p1.rel_path_to(p2)

## -- End pasted text --
b/c/d
..

I do not quite understand why the first call returns b/c/d I would expect that the relative path of /a/b/c/d/ w.r.t. a/b is c/d. Indeed this is what pathlib yields:

In [39]: %paste
from pathlib2 import Path
p1 = Path('/a/b')
p2 = Path('/a/b/c/d')
print p2.relative_to(p1)

## -- End pasted text --
c/d

Note that the calling convention is also different: p2.relative_to(p1) is arguably more intuitive compared to p1.rel_path_to(p2).

Python 2.7.12

>>> import marshal
>>> import unipath
>>> path=unipath.Path('/home')
>>> marshal.dumps(path)
's\x05\x00\x00\x00/home'

Python 3.5.2

>>> import marshal
>>> import unipath
>>> path=unipath.Path('/home')
>>> marshal.dumps(path)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unmarshallable object

Today I fell into a pitfall with unipath (the first time after
more than a year). Here is an excerpt from some of my code::

jarfile = outdir.child(n)
libfile = LIBDIR.child(n)
if libfile.needs_update([jarfile]):
    libfile.copy(jarfile)

In a first attempt I had written::

if libfile.needs_update(jarfile):

which gave me a strange traceback::

Traceback (most recent call last):
  ...
  File "/home/luc/hgwork/eid/fabfile.py", line 40, in sign_jars
    if libfile.needs_update(jarfile):
  File "/home/luc/pythonenvs/py27/local/lib/python2.7/site-packages/unipath/path.py", line 298, in needs_update
    if p.isdir():
AttributeError: 'str' object has no attribute 'isdir'

Yes, the documentation clearly says that the argument to needs_update must be an iterable, and that Path objects behave like strings... and to avoid that pitfall, unipath would have to test on each whether it is a directory or not... so my suggestion is to just update the documentation to warn about this pitfall.

from unipath import Path, tools

p = Path()
tools.dump_path(p)

Output:

Traceback (most recent call last):
  File "C:\Users\sesas\Documents\My Dropbox\Python Scripts\tests\unipath_test.py", line 5, in <module>
    tools.dump_path(p)
  File "C:\Python27\lib\site-packages\unipath\tools.py", line 28, in dump_path
    elif p.isdir():
TypeError: _isdir() takes exactly 1 argument (0 given)

When we need to copy a file to a directory and I use src.copy(dst) I get a IsADirectoryError: [Errno 21] Is a directory error from shutil.copyfile. This means I cannot do a simple operation of coping a file to another directory using the Path object, which can be done by using shutil.copy.

Why don't we use shutil.copy instead of shutil.copyfile so the basic copy operation too can be executed ?

When I tried to install via pip, I got the following error:

Installing collected packages: unipath
  Running setup.py install for unipath
      File "/usr/local/lib/python3.3/dist-packages/unipath/path.py", line 197
        fd = os.open(self, os.O_WRONLY | os.O_CREAT, 0666)
                                                        ^
    SyntaxError: invalid token

      File "/usr/local/lib/python3.3/dist-packages/unipath/test.py", line 48
        except Exception, e:
                        ^
    SyntaxError: invalid syntax

It means it is just 2 minor changes to make it Python 3 compatible.

I followed the instructions on the README exactly and this is the output:

C:\GitHub\Unipath>pytest test.py
=============================  test.py  ==============================

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK
*******************************************************************************

As you @mikeorr mentioned, theres path.py by Jason Orendorff, pathlib from PEP 428, and a couple of other path.py forks similar to this one.

There is also a currently maintained path.py fork by Jason R. Coombs. Figured it's worth a mention as an alternative or as a comparison. Here's the link: https://pypi.python.org/pypi/path.py

I don't know if this was mentioned before, but I figured it should be brought up in the comparisons. I found out about it through the following StackOverflow question: http://stackoverflow.com/questions/3899761/will-the-real-path-py-please-stand-up/7923330#7923330

Path.copy_stat always copies both mtime/atime and mode, regardless of the times and perms args it is passed. Given the implementation of Path.copy, this means only times=True,perms=True and times=False,perms=False work properly. Passing True,False or False,True results in both times and perms being copied.

The Unipath API has long been used in production so I'm not inclined to change it much. At the same time, it would be nice to converge on a Python path standard.
path.py is still around, but the other pre-Unipath distributions have become niche products or fallen away. But now there's PEP 428 (pathlib), which has a different and more modern API. So should we do anything to modernize or converge?

PEP 428 is still in draft status, and as of last year when I talked with Antoine Pitrou, 'pathlib' had not gotten much use so its API couldn't be considered tested. Pathlib was also missing some of Unipath's features. I'm not inclined to break Unipath's backward compatibility because of its long-time use. Yet in my own new applications I'm undecided whether to keep using Unipath, switch to pathlib, or write something new (perhaps porting Unipath's features to pathlib).

So, should we do anything about this?