On 5/4/06, Paul Moore <[EMAIL PROTECTED]> wrote: > On 5/4/06, Nick Coghlan <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> ([EMAIL PROTECTED] address is semi-reliable) _______________________________________________ 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
