comp.lang.python

sluggoster@gmail.com

3/9/2010 11:18:00 PM

I just saw this thread on the Python-URL.

On Feb 14, 12:39 pm, a...@pythoncraft.com (Aahz) wrote:
> >> Sean DiZazzo =A0<half.ital...@gmail.com> wrote:
>
> >>>Why did Path() get rejected? Is it the idea itself, or just the
> >>>approach that was used? What are the complaints?
>
> >> You should search for the discussiona around it.
>
> >I read the discussion, and there was definitely some going back and
> >forth on whether it should be sub-classed from string, but the
> >conversation just seemed to stop abruptly with no decision one way of
> >the other.  Maybe I missed a thread.

It has a habit of being discussed and dropped repeatedly. The main
issue is that Guido doesn't see an OO approach as necessarily better
than the existing functions, so it has a high bar for acceptance. One
issue is that some people see a need to separate filesystem-
independent functionality (joining paths and extracting components)
from filesystem-dependent functionality (listing directories, removing
files, etc). ``path.py`` and PEP 355 were rejected mainly because of
this. There was support for a small filesystem-independent class that
could be put into the stdlib, and some modest moving/renaming of the
filesystem functions (which are scattered across os, os.path, shutil,
glob, etc). We were hoping to get this done for Python 3 but didn't
make it. I wrote a ``Unipath`` package that tried to be a compromise
between what everybody wanted, with a FS-independent class and a FS-
dependent subclass, but could not get any feedback on it. Somebody
else was going to write a PEP for the renamings, but I never saw it.

Since then, path.py has been included in a couple packages and seems
to have the most widespread use. I gave up on the stdlib and
reconfigured Unipath as a pure 3rd-party library. (The FS-independent
AbstractPath class is still there if anybody wants to use it for a
PEP.) The other people who made their own implementations seemed to be
happy with theirs, and that was that.

The string vs non-string argument has pretty much been decided in
favor of strings (i.e., a string subclass). Not ``"a.txt".open()`` but
``open(Path("a.txt"))``. Too many standard and 3rd-party modules
expect string paths: you'd have to convert your path to a string every
time you pass it as an argument. The main problem with string paths
is that .join() means something else, but that's usually solved by
using a different method name: "joinpath", "child", "/", etc.

Other proposals have been a tuple subclass, so that ``Path("a/b/c.txt")
[-1] == Path("c.txt")``, and a library that can do non-native paths
(Windows style on Unix systems and vice-versa). These don't seem to be
in vogue anymore.

What has become more common is virtual paths; i.e., the same interface
for filesystems, FTP, zip files, etc. That was discussed during the
last go-around but there were no implementations. Now there are a few
projects active on this, such as http://groups.google.com/gro...
.. This is probably the future of any path object, so it would make
sense to define a path now that can work with all these backends.

--Mike