Steve Dower added the comment: It's no less expected than having OS functions fail because the path is too long.
Using it to maintain dots at the end of directory/file names is a little less safe and may break some code. Maybe pathlib should strip these if there is no a prefix? (For example, "C:\Test." == "C:\Test" == "\\?\C:\Test" != "\\?\C:\Test.") If most (or all) of the file handling functions in Python are using *W() APIs and can support the prefix, I'd rather add it in silently if only to avoid the long path issue. It's really the sort of implementation detail that pathlib should be able to hide from the app developer and the user (Node.js does this, for example, as its node_modules hierarchies regularly exceed the max path limitation). Maybe the best approach is to preserve the prefix if it already exists, and add it if it becomes necessary. File operations are most likely to succeed in this case, even if it may be surprising to users. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22299> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
