just at xs4all.nl
Tue Jul 8 10:17:16 CEST 2003
In article <mailman.1057651032.22842.python-list at python.org>,
Ian Bicking <ianb at colorstudy.com> wrote:
> I think Jason Orendorff's path module is really nice:
> Beats the hell out of os.path, which is an ugly thing indeed. The OO
> interface means you could use the interface nicely to implement other
> things, like URLs. The problem? It's just some module. The various os
> functions (of which path replaces quite a few) have become idiomatic to
> me, and I'm sure others as well. I find myself reluctant to use it in
> code that's not essentially private, because it's changing something
> small and seemingly trivial, and people won't be familiar with it.
> The solution? It should be a builtin! Or, if not a builtin, included
> in the os module. But I actually like the idea of it being a builtin --
> if open is a builtin, path stands right up there too. It would get rid
> of 90% of the use of the os module.
> Thoughts? Reactions?
I would greatly appreaciate such a module in the std library, but while
Jason's module has some very cool features, to my taste it goes a bit
too far with overloading operators. I really don't like overloading a/b
to mean os.path.join(a, b) and I don't think the default iterator should
do a listdir (although list(mypath) is indeed cute). If it were toned
down a bit in this area I think we may be able to make a good case for
including it in the std library.
More information about the Python-list