[Python-Dev] The path module PEP

[Ian Bicking]

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