path module / class

[chris.atlee]

Hi there,

I haven't seen this topic pop up in a while, so I thought I'd raise it
again...

What is the status of the path module/class PEP? Did somebody start
writing one, or did it die? I would really like to see something like
Jason Orendorff's path class make its way into the python standard
library.

It seems like this comes up every so often, prompts some discussion,
and then fizzles :)

Last I checked on python-dev, people were mostly in agreement that the
path module could be added, with a few modifications. (The top of the
thread is here: http://thread.gmane.org/gmane.comp.python.devel/69403)

A few issues that were left unresolved by that thread were:
- should joinpath() be called subpath()? I think joinpath is fine, it
agrees with os.path
- should listdir() be called subpaths()? I don't think so, would
listpaths() be a good alternative?
- drop getcwd() method?
- what the class / module should actually be called, and where should
it live?
- unicode support
- timestamp / datetime objects for mtime/ctime/atime functions

Cheers,
Chris

[Dennis Benzinger]

ch*********@gma il.com schrieb:

[...]
What is the status of the path module/class PEP? Did somebody start
writing one, or did it die?
I didn't find one at the PEP index <http://python.org/peps/>, so I
assume that nobody wrote or submitted one.
I would really like to see something like
Jason Orendorff's path class make its way into the python standard
library.
[...]

If you think having such a class in the standard library is that
important then you should write a PEP by yourself...
Bye,
Dennis

[Dennis Benzinger]

ch*********@gma il.com schrieb:

[...]
What is the status of the path module/class PEP? Did somebody start
writing one, or did it die?
I didn't find one at the PEP index <http://python.org/peps/>, so I
assume that nobody wrote or submitted one.
I would really like to see something like
Jason Orendorff's path class make its way into the python standard
library.
[...]

If you think having such a class in the standard library is that
important then you should write a PEP by yourself...
Bye,
Dennis

[Neil Hodgson]

Chris:

What is the status of the path module/class PEP? Did somebody start
writing one, or did it die? I would really like to see something like
Jason Orendorff's path class make its way into the python standard
library.

There is no PEP yet but there is a wiki page.
http://wiki.python.org/moin/PathClass
Guido was unenthusiastic so a good step would be to produce some
compelling examples.

Neil

[Neil Hodgson]

Chris:

What is the status of the path module/class PEP? Did somebody start
writing one, or did it die? I would really like to see something like
Jason Orendorff's path class make its way into the python standard
library.

There is no PEP yet but there is a wiki page.
http://wiki.python.org/moin/PathClass
Guido was unenthusiastic so a good step would be to produce some
compelling examples.

Neil

[chris.atlee]

Hi Neil,

Neil Hodgson wrote:
[snip]

There is no PEP yet but there is a wiki page.
http://wiki.python.org/moin/PathClass
Guido was unenthusiastic so a good step would be to produce some
compelling examples.

I guess it depends on what is "compelling " :)

I've been trying to come up with some cases that I've run into where
the path module has helped. One case I just came across was trying to
do the equivalent of 'du -s *' in python, i.e. get the size of each of
a directory's subdirectories. My two implemenations are below:

import os
import os.path
from path import path

def du_std(d):
"""Return a mapping of subdirectory name to total size of files in
that subdirectory, much like 'du -s *' does.

This implementation uses only the current python standard
libraries"""
retval = {}
# Why is os.listdir() and not os.path.listdir ()?
# Yet another point of confusion
for subdir in os.listdir(d):
subdir = os.path.join(d, subdir)
if os.path.isdir(s ubdir):
s = 0
for root, dirs, files in os.walk(subdir) :
s += sum(os.path.get size(os.path.jo in(root,f)) for f in
files)
retval[subdir] = s
return retval

def du_path(d):
"""Return a mapping of subdirectory name to total size of files in
that subdirectory, much like 'du -s *' does.

This implementation uses the proposed path module"""
retval = {}
for subdir in path(d).dirs():
retval[subdir] = sum(f.getsize() for f in subdir.walkfile s())
return retval

I find the second easier to read, and easier to write - I got caught
writing the first one when I wrote os.path.listdir () instead of
os.listdir().

Cheers,
Chris

[chris.atlee]

Hi Neil,

Neil Hodgson wrote:
[snip]

There is no PEP yet but there is a wiki page.
http://wiki.python.org/moin/PathClass
Guido was unenthusiastic so a good step would be to produce some
compelling examples.

I guess it depends on what is "compelling " :)

I've been trying to come up with some cases that I've run into where
the path module has helped. One case I just came across was trying to
do the equivalent of 'du -s *' in python, i.e. get the size of each of
a directory's subdirectories. My two implemenations are below:

import os
import os.path
from path import path

def du_std(d):
"""Return a mapping of subdirectory name to total size of files in
that subdirectory, much like 'du -s *' does.

This implementation uses only the current python standard
libraries"""
retval = {}
# Why is os.listdir() and not os.path.listdir ()?
# Yet another point of confusion
for subdir in os.listdir(d):
subdir = os.path.join(d, subdir)
if os.path.isdir(s ubdir):
s = 0
for root, dirs, files in os.walk(subdir) :
s += sum(os.path.get size(os.path.jo in(root,f)) for f in
files)
retval[subdir] = s
return retval

def du_path(d):
"""Return a mapping of subdirectory name to total size of files in
that subdirectory, much like 'du -s *' does.

This implementation uses the proposed path module"""
retval = {}
for subdir in path(d).dirs():
retval[subdir] = sum(f.getsize() for f in subdir.walkfile s())
return retval

I find the second easier to read, and easier to write - I got caught
writing the first one when I wrote os.path.listdir () instead of
os.listdir().

Cheers,
Chris

[Peter Hansen]

Neil Hodgson wrote:

Chris:

What is the status of the path module/class PEP? Did somebody start
writing one, or did it die? I would really like to see something like
Jason Orendorff's path class make its way into the python standard
library.

There is no PEP yet but there is a wiki page.
http://wiki.python.org/moin/PathClass
Guido was unenthusiastic so a good step would be to produce some
compelling examples.

Compelling to whom? I wonder if it's even possible for Guido to find
compelling anything which obsoletes much of os.path and shutil and
friends (modules which Guido probably added first and has used the most
and feels most comfortable with).

Personally, I find almost all uses of path.py to be compelling, most
especially when I consider it from the points of view of "readabilit y",
"explicitne ss", "beauty", "simple", "flat", let alone "practical"
(having all those tools in one place). Those were all from Tim
channeling Guido, but perhaps it was a noisy channel... And Guido's
views on consistency are well documented ;-) so the fact that the
alternative to path.py is incredibly inconsistent probably has no weight
in the argument.

Not so facetiously though: if the examples given haven't proven
compelling, is it realistic to think that someone will dig up an example
which suddenly changes Guido's mind? I suspect it's more realistic to
think, as with the ternary operator, that he either will or won't, and
examples proposed from outside won't have much if any impact on his
thinking.

-Peter

[Peter Hansen]

Neil Hodgson wrote:

Chris:

What is the status of the path module/class PEP? Did somebody start
writing one, or did it die? I would really like to see something like
Jason Orendorff's path class make its way into the python standard
library.

There is no PEP yet but there is a wiki page.
http://wiki.python.org/moin/PathClass
Guido was unenthusiastic so a good step would be to produce some
compelling examples.

Compelling to whom? I wonder if it's even possible for Guido to find
compelling anything which obsoletes much of os.path and shutil and
friends (modules which Guido probably added first and has used the most
and feels most comfortable with).

Personally, I find almost all uses of path.py to be compelling, most
especially when I consider it from the points of view of "readabilit y",
"explicitne ss", "beauty", "simple", "flat", let alone "practical"
(having all those tools in one place). Those were all from Tim
channeling Guido, but perhaps it was a noisy channel... And Guido's
views on consistency are well documented ;-) so the fact that the
alternative to path.py is incredibly inconsistent probably has no weight
in the argument.

Not so facetiously though: if the examples given haven't proven
compelling, is it realistic to think that someone will dig up an example
which suddenly changes Guido's mind? I suspect it's more realistic to
think, as with the ternary operator, that he either will or won't, and
examples proposed from outside won't have much if any impact on his
thinking.

-Peter

[Neil Hodgson]

Peter Hansen:

Compelling to whom? I wonder if it's even possible for Guido to find
compelling anything which obsoletes much of os.path and shutil and
friends (modules which Guido probably added first and has used the most
and feels most comfortable with).

To me, most uses of path.py are small incremental improvements over
os.path rather than being compelling. Do a number of small improvements
add up to be large enough to make this change? There is a cost to the
change as there will be two libraries that have to be known to
understand code. Does someone have an example application that moved to
path.py with a decrease in errors or noticeable decrease in complexity?
Could all path manipulation code be switched or is coverage incomplete?

The duplication argument should be answered by looking at all the
relevant modules and finding a coherent set of features that work with
path.py without overlap so that the obsolete methods can be deprecated.
If adding path.py leads to a fuzzy overlapping situation where os.path
is occasionally useful then we are complicating the user's life rather
than simplifying it.

Neil