[Python-Dev] Alternative path suggestion

Mike Orr sluggoster at gmail.com
Fri May 5 09:26:45 CEST 2006


On 5/4/06, Paul Moore <p.f.moore at gmail.com> wrote:
> On 5/4/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > My inclination was to have a PlatformPath subclass that accepted 'os', 'sep'
> > and 'extsep' keyword arguments to the constructor, and provided the
> > appropriate 'sep' and 'extsep' attributes (supplying 'os' would just be a
> > shortcut to avoid specifying the separators explicitly).
> >
> > That way the main class can avoid being complicated by the relatively rare
> > need to operate on another platform's paths, while still supporting the ability.
>
> You ought to have predefined classes for the standard OSes. Expecting
> people to know the values for sep and extsep seems unhelpful.
>
> In fact, unless you expect to support the os.path interface forever,
> as well as the new interface,  I'd assume there would have to be
> internal WindowsPath and PosixPath classes anyway - much like the
> current ntpath and posixpath modules. So keeping that structure, and
> simply having
>
> if os.name == 'posix':
>     Path = PosixPath
> elif os.name == 'nt':
>     Path = WindowsPath
> ... etc
>
> at the end, would seem simplest.

Why not just put a platform-specific Path class inside posixpath,
macpath, etc.  Python already chooses os.path for the actual platform,
and you can import a foreign module directly if you want to.

> (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.

- Discourage os.path.foo() in the documentation but continue to support it.

- Rewrite os.path.foo() to use Path.foo().  A lot of useless work if we...

- Remove os.path.foo() in Python 3.0.

--
Mike Orr <sluggoster at gmail.com>
(mso at oz.net address is semi-reliable)


More information about the Python-Dev mailing list