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