22

There was a good module, path.py, written by Jason Orendorff. If I recall correctly, there was some discussion about adding it to the standard library then it faded away.

It looks now that there are multiple outgrowths of the original one. I can find so far unipath, what looks like a forked path.py, another one, and a few others according to PyPI.

Anyone has experience with any of those options? Is one better than the other in terms of functionality, maintenance or any other criteria? Or should I just pick one at random?

(Apologies for the whimsical title. I first went for "Which path.py?" but it was too short for SO's taste.)

Muhammad Alkarouri
  • 23,884
  • 19
  • 66
  • 101
  • 8
    Hi, my name is *what* my name is *WHAT* my name is path.py. – Ignacio Vazquez-Abrams Oct 10 '10 at 09:50
  • 2
    The discussion morphed into PEP 355 (http://www.python.org/dev/peps/pep-0355/) which was eventually rejected by GvR (http://article.gmane.org/gmane.comp.python.devel/84061) – Ned Deily Oct 10 '10 at 15:48
  • 1
    "rejected" - to quote him literally, "PEP 355 is dead". Why so? More importantly, is there a replacement PEP for the better? – n611x007 Aug 28 '12 at 08:35
  • Too bad the PEP is rejected. I use 'path.py' all the time (not sure where mine comes from). I guess the rejection comes down to subclassing from 'str' and having too much functionality. My 'path.py' doesn't subclass from 'str', but I love having the kitchen sink included when I write real code. I even love the '/' operator overload. Rarely does that get confused with divide. – noisygecko Nov 05 '12 at 15:04
  • I just looked and it appears that the 'path.py' I have been using does subclass 'str' (or 'unicode'). I am using one which is originally by Jason Orendorff. I really don't run into a problem with it subclassing from 'str'. I might guess that those who think that is a bad idea have never used it. – noisygecko Nov 05 '12 at 20:57
  • @noisygecko I think the problem is what makes it so great: It deprecates a lot of widely used standard modules, modules used to an extent that there's little hope of ever pushing them out of the standard library, unless another breaking version increase takes place (which might never happen). Zen of Python says: There should be exactly one way to solve things. It stings, but they're right, the new module would introduce ambiguity & clutter. – Nearoo Feb 05 '22 at 18:51
  • @Nearoo Wow, this is an old thread. There now is the pathlib standard module, and even pathlib2 that I guess is a newer one that I should start using. I haven't used path.py in many years although I guess I still have scripts that use it that I wrote a long time ago. – noisygecko Feb 06 '22 at 19:15
  • @noisygecko True! `pathlib` has most things that `path` does, I didn't even realize. Guess I was wrong about the Python Zen. `pathlib2` seems to be a deprecated version of `pathlib`. The fact remains though that there are now two solutions to one problem, and the old one (`os`) will likely remain for a long time – Nearoo Feb 06 '22 at 20:25

2 Answers2

10

I've also been a fan of this module for quite some time. This one seems to have the most recent commits, and also to be true to the original form -- which really, I like best of the different versions I've tried. Installable using pip install path.py

edit: Looks like as of python 3.4 (and backported to 2.7 on PYPI), there's a standard lib path module called pathlib. It's not nearly as extensive as some of the path modules are, but it benefits from the lack of clutter, and it is a well-thought-out path implementation, retaining some of the best base qualities of quite a few of the path libraries that are out there. Particularly of note, it cleanly handles the differences between different OS paths (Windows and Posix), and seems like a good clean tool that's worth a look. Regardless of whether it has every feature one could ever want or not (it doesn't), it's nice that Python finally has a good standard path implementation.

Mr. B
  • 2,536
  • 1
  • 26
  • 26
  • 1
    https://github.com/jaraco/path.py is the most maintained now I think. it has also new features like http://stackoverflow.com/questions/169070/python-how-do-i-write-a-decorator-that-restores-the-cwd/14019583#14019583 – CharlesB Dec 27 '12 at 05:22
  • 1
    Good notice -- he's actually the maintainer of 'path.py' on pypi now, too. I've updated my post to reflect the difference. – Mr. B Feb 26 '13 at 22:49
4

All path.py fans stand up!

Since Python 3.4, a module is dealing with paths, module pathlib. It is based on PEP 428, and heavily inspired from our beloved path.py, though seems to take some different approach notably on a strong distinction between Windows path and Unix path.

CharlesB
  • 86,532
  • 28
  • 194
  • 218
  • 1
    But although it was backported, they don't want anything to do with Python 2 (see [#25 (wontfix)](https://bitbucket.org/pitrou/pathlib/issue/25), and bytes vs unicode makes it non-interoperable anyway). Also the whole "pretending bytes are unicode" and their `surrogateescape` encoding makes it very wonky if you ask me. – remram Jun 06 '14 at 00:40