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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4