[Python-Dev] Alternative path suggestion

[Nick Coghlan]

Mike Orr wrote:
> On 5/4/06, Paul Moore <p.f.moore at gmail.com> wrote:
>> (But all the current proposals seem to build on os.path, so maybe I
>> should assume otherwise, that os.path will remain indefinitely...)
> 
> They build on os.path because that's what we're familiar with using. 
> There's no reason to write the platform-specific classes until we
> agree on an API; that would just be work down the drain.  When the new
> classes are in the library, we can:  (one or more)
> 
> - Leave os.path.foo() alone because it works and most existing programs need it.

The threading module doesn't really obsolete the thread module, it just 
provides a higher level, more convenient API.

Similarly, I don't believe it's a given that a nice path object will obsolete 
the low level operations. When translating a shell script to Python (or vice 
versa), having access to the comparable low level operations would be of benefit.

At most, I would expect provision of an OO path API to result in a comment in 
the documentation of various modules (os.path, shutil, fnmatch, glob) saying 
that "pathlib.Path" (or whatever it ends up being called) is generally a more 
convenient API.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org