[Python-Dev] Path object design

[Georg Brandl]

Fredrik Lundh wrote:
> Talin wrote:
> 
>> I'm right in the middle of typing up a largish post to go on the 
>> Python-3000 mailing list about this issue. Maybe we should move it over 
>> there, since its likely that any path reform will have to be targeted at 
>> Py3K...?
> 
> I'd say that any proposal that cannot be fit into the current 2.X design 
> is simply too disruptive to go into 3.0.  So here's my proposal for 2.6 
> (reposted from the 3K list).
> 
> This is fully backwards compatible, can go right into 2.6 without 
> breaking anything, allows people to update their code as they go,
> and can be incrementally improved in future releases:
> 
>      1) Add a pathname wrapper to "os.path", which lets you do basic
>         path "algebra".  This should probably be a subclass of unicode,
>         and should *only* contain operations on names.
> 
>      2) Make selected "shutil" operations available via the "os" name-
>         space; the old POSIX API vs. POSIX SHELL distinction is pretty
>         irrelevant.  Also make the os.path predicates available via the
>         "os" namespace.
> 
> This gives a very simple conceptual model for the user; to manipulate
> path *names*, use "os.path.<op>(string)" functions or the "<path>"
> wrapper.  To manipulate *objects* identified by a path, given either as
> a string or a path wrapper, use "os.<op>(path)".  This can be taught in
> less than a minute.

+1. This is really straightforward and easy to learn.

I have been a supporter of the full-blown Path object in the past, but the
recent discussions have convinved me that it is just too big and too confusing,
and that you can't kill too many birds with one stone in this respect.
Most of the ugliness really lies in the path name manipulation functions, which
nicely map to methods on a path name object.

Georg