Prev: [Off topic] Radian language
Next: Python 3 minor irritation
From: Mike Orr on 9 Mar 2010 18:18
I just saw this thread on the Python-URL.

On Feb 14, 12:39 pm, a...(a)pythoncraft.com (Aahz) wrote:
> >> Sean DiZazzo =A0<half.ital...(a)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/group/stdpyfs
.. 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
From: Martin P. Hellwig on 9 Mar 2010 18:58
On 02/09/10 14:00, Phlip wrote:
<cut>
> Ah, now we get down to the root of the problem. Because Python is so
> stuck on the "one best way to do it" mentality, language bigotry
> prevented the Committee from picking from among several equally valid
> but non-best options. And after 20 years of growth, Python still has
> no Pathname class. What a mature community! C-:
>
<cut>
Well even if this statement would be true, I personally think that not
proclaiming something a 'standard' if you are sure that you are not sure
about it, is a virtue.

--
mph
From: Phlip on 10 Mar 2010 11:54
Martin P. Hellwig wrote:

> Well even if this statement would be true, I personally think that not
> proclaiming something a 'standard' if you are sure that you are not sure
> about it, is a virtue.

In terms of trying too hard to achieve perfection, am I missing a
Python repository similar to the C++ Boost project? All the nice-to-
have classes that extend the core of C++ get to live in Boost before
the C++ Committee pulls the best ideas off the top and add them to the
Standard Library...

--
Phlip
http://penbird.tumblr.com/
From: Chris Rebert on 10 Mar 2010 12:15
On Wed, Mar 10, 2010 at 8:54 AM, Phlip <phlip2005(a)gmail.com> wrote:
> Martin P. Hellwig wrote:
>> Well even if this statement would be true, I personally think that not
>> proclaiming something a 'standard' if you are sure that you are not sure
>> about it, is a virtue.
>
> In terms of trying too hard to achieve perfection, am I missing a
> Python repository similar to the C++ Boost project? All the nice-to-
> have classes that extend the core of C++ get to live in Boost before
> the C++ Committee pulls the best ideas off the top and add them to the
> Standard Library...

The next closest thing would probably be the Python Cookbook:
http://code.activestate.com/recipes/langs/python/

However, such stuff can also be found as third-party modules.

Cheers,
Chris
--
http://blog.rebertia.com
From: Phlip on 16 Mar 2010 12:12
Chris Rebert wrote:

> The next closest thing would probably be the Python Cookbook:http://code.activestate.com/recipes/langs/python/

One thing I really like about ... my hacked version of path.py ... is
path.cd( lambda: ... ). It works great inside fabfile.py to
temporarily switch to a different folder:

sample_project = path('sample_project').abspath()

def run():
sample_project.cd( lambda:
_sh('python manage.py runserver 0.0.0.0:8000 --
settings=test_settings') )

After the lambda runs, we exception-safely return to the home folder.

(BTW I'm aware that a fabfile.py command with only one statement will
return to its shell and remain in the correct folder. It's just ...
the thought!)

This be .cd():

class path:

def cd(self, block=None):
previous = path(os.path.curdir).abspath()
self.chdir()

if block:
try: block()
finally: previous.chdir()

That's based on Jason Orendoff's work at http://www.jorendorff.com/articles/python/path

--
Phlip
http://c2.com/cgi/wiki?ZeekLand
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: [Off topic] Radian language
Next: Python 3 minor irritation