[Python-Dev] guidance sought: merging port related changes to Library modules
Tim Peters
tim.one@home.com
Sun, 13 Jan 2002 02:39:17 -0500
[Guido]
> The various modules ntpath, posixpath, macpath etc. are not just their
> to support their own platform on itself. They are also there to
> support foreign pathname twiddling. E.g. On Windows I might have a
> need to munge posix paths -- I can do that by explicitly importing
> posixpath. Likewise the reverse.
Bingo.
> So I think changing ntpath.py to use os.set etc. would be wrong, and
> creating a new file os2emxpath.py is the right thing to do -- despite
> the endless cloning of the same code. :-( (Maybe a different way to
> share more code between the XXXpath modules could be devised.)
Create _commonpath.py and put shared routines there. Then a blahpath.py can
do
from _commonpath import f, g, h
to re-export them.
An excellent candidate for inclusion would be expandvars(): the different
routines for that now have radically different behaviors in endcases, it's
impossible to say which are bugs or features, yet the routine *should* be
wholly platform-independent (no, the Mac doesn't need its own version --
when an envar isn't found, the $envar token is retained literally). Having
different versions of walk() is also silly, ditto isdir(), etc.