[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4