[Python-Dev] The path module PEP (original) (raw)

Ian Bicking ianb at colorstudy.com
Tue Jan 24 22:28:05 CET 2006

Charles Cazabon wrote:

BJörn Lindqvist <bjourne at gmail.com> wrote:

1. Make all python files in the a directory executable: [...] ==> for f in Path('/usr/home/guido/bin'): f.chmod(0755) Iterating over a path string to read the contents of the directory possibly pointed to by that string seems like "magic implicit" behaviour. Perhaps making it a method explicitly returning an iterator would by more Pythonic? for f in Path(...).readDir():

I believe .listdir() exists already as a method alternative. I'm -0 on iteration as listdir. Doing iteration like strings (over the characters) would be evil.

4. Splitting a path into directory and filename: [...]

Path("/path/to/foo/bar.txt").splitpath() Good. But the opposite isn't done similarly:

6. Create directory paths: [...] Path("foo") / "bar" / "baz" Using "/" as "path concatenation operator" seems like un-Pythonic magic as well (while "+" would be an improvement, it's still not a large one). I would think Path('foo').appendparts('bar', 'baz') or similar would be more readable and obvious.

.joinpath() does this. Though .join() does something else entirely that it inherits from strings, something evil to do with a path, and I think that method should raise NotImplementedError. + should not be overridden, because strings define that.

Some other str methods are harmless but pointless: center, expandtabs, ljust, zfill; title, capitalize, and istitle are iffy. Also, are there any particular cases where string methods on a path produce an actual str, not another Path object?

-- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org

More information about the Python-Dev mailing list