On Sat, 12 Jan 2002, Guido van Rossum wrote:
> 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.
>
> 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.)
I'd not considered the foreign path munging use, which I agree justifies
retaining hardcoded path separators.
I'll proceed on the basis of the os2emxpath.py approach. I'll pass for
the time being on Tim's suggested rationalisation approach though...
Thanks for the enlightment.
--
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andymac@bullseye.apana.org.au | Snail: PO Box 370
andymac@pcug.org.au | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
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