Mike Orr wrote:
> On 5/4/06, Paul Moore <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
