On Feb 4, 7:10 pm, Sean DiZazzo <half.ital...@gmail.com> wrote:
> On Feb 3, 6:08 pm, alex23 <wuwe...@gmail.com> wrote:
>
>
>
> > On Feb 4, 8:47 am, Phlip <phlip2...@gmail.com> wrote:
>
> > > Yes, calling os.path.walk() and os.path.join() all the time on raw
> > > strings is fun, but I seem to recall from my Ruby days a class called
> > > Pathname, which presented an object that behaved like a string at
> > > need, and like a filesystem path at need. path + 'folder' would
> > > call .join() and insert the / correctly, for example.
>
> > > What's the best equivalent in Python-land?
>
> > It's no longer supported, but the 3rd party 'path' module used to be
> > the go-to module for this:
>
> > >>> from path import path
>
> > C:\Python26\lib\site-packages\path.py:32: DeprecationWarning: the md5
> > module is deprecated; use hashlib instead
> > import sys, warnings, os, fnmatch, glob, shutil, codecs, md5>>> c =
> > path('C:\\')
> > >>> c.listdir()
>
> > [path(u'C:\\AUTOEXEC.BAT'), path(u'C:\\boot.ini'), ...]>>> (c +
> > 'python26').listdir()
>
> > [path(u'C:\\python26\\circuits.pth_disabled_for_egg'), path(u'C:\
> > \python26\\DLLs'), ...]>>> (c / 'python26').listdir()
>
> > [path(u'C:\\python26\\circuits.pth_disabled_for_egg'), path(u'C:\
> > \python26\\DLLs'), ...]
>
> > I've hand edited the results for brevity...
>
> > The module could do with some TLC to bring it up to date, but warning
> > aside it still seems to work fine under 2.6.
>
> > (From memory, I think the original author gave up when it became clear
> > it would never be integrated into the standard lib[1], which is a
> > shame, I think there's scope for a pathtools addition to the lib that
> > provides this level of convenience...)
>
> > There was also a PEP with another possible
> > implementation:http://www.python.org/dev/peps/pep-0355/
>
> > Hope this helps.
>
> It's too bad that something like this can't be agreed to. I used a
> homegrown module like this for a couple of years in my early days with
> python. It was great, but I didn't know enough at the time to make it
> really useful.
>
> Why did Path() get rejected? Is it the idea itself, or just the
> approach that was used? What are the complaints?
I don't know if it was the reason it was rejected, but a seriously
divisive question is whether the path should be a subset of string.
Under ordinary circumstances it would be a poor choice for inheritance
(only a few string methods would be useful fot a pathname), but some
people were fiercely adamant that paths should be passable to open()
as-in (without having to explicity convert to string). IIRC, the guy
who maintained path wavered between subclassing and not subclassing
str. I don't remember if the idea of modifying open to accept path
objects came up.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
