equivalent of Ruby's Pathname?
in [Python]
|
From: Phlip on 3 Feb 2010 17:47 Pythonistas: 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? -- Phlip
From: alex23 on 3 Feb 2010 21:08 On Feb 4, 8:47 am, Phlip <phlip2...(a)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.
From: Sean DiZazzo on 4 Feb 2010 22:10 On Feb 3, 6:08 pm, alex23 <wuwe...(a)gmail.com> wrote: > On Feb 4, 8:47 am, Phlip <phlip2...(a)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? ~Sean
From: Aahz on 8 Feb 2010 17:36 In article <dcace5fc-5ae9-4756-942d-6da7da2f660d(a)s36g2000prh.googlegroups.com>, Sean DiZazzo <half.italian(a)gmail.com> wrote: >On Feb 3, 6:08=A0pm, alex23 <wuwe...(a)gmail.com> wrote: >> >> There was also a PEP with another possible implementation: >> http://www.python.org/dev/peps/pep-0355/ > >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. -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ import antigravity
From: Phlip on 8 Feb 2010 17:46
On Feb 8, 2:36 pm, a...(a)pythoncraft.com (Aahz) wrote: > >> There was also a PEP with another possible implementation: > >>http://www.python.org/dev/peps/pep-0355/ > > >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, OTOH, am burning rubber with Python 2.6.1, so leading edge concerns are not mine - yet! I went with this version, generously ripped out & plopped into our project: # URL: http://www.jorendorff.com/articles/python/path # Author: Jason Orendorff <jason(a)jorendorff.com> (and others - see the url!) # Date: 7 Mar 2004 class path(_base): """ Represents a filesystem path. """ Gods bless http://www.google.com/codesearch, huh?! -- Phlip http://c2.com/cgi/wiki?ZeekLand |