> with the > rationale being the one someone mentioned regarding ease-of-use in > os.path. > > Consider os.path.join:
Why in the world do the os.path functions need to work with Path objects? ( and other conforming objects) Thus all started with the goal of using Path objects in the stdlib, but that's for opening files, etc. Path is an alternative to os.path -- you don't need to use both. And if you do have a byte path, you can stick with os.path.... BTW, I'm confused about what a bytes path IS -- is it encoded? Can you assume it can be decoded ? It seems to me that the ONLY time you should get a byte path is from a low level system call on a posix system, and you may have no idea how it's encoded. So the ONLY thing you should do with it is pass it along to another low level system call. I can't see why we should support anything else with bytes objects. > - the names would be fspath and __fspath__, since the result may be > either a path name as text, or an encoded path name as bytes You just used the phrase "path name as bytes" -- so why is __pathname__ inappropriate if it might return bytes? I like __pathname__ better because this entire effort is because we' be decided itMs important to make the distinction between a "path" and the text representation of said path. Just sayin' -CHB _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
