Many of the tempfile modules' classes and utils could maybe return Path instead of str. I'm not sure how disruptive that would be, but I would definitely welcome something that avoids having to wrap everything in Path.
I think they might need to return a "StrPath" for compatibility, but IMHO only for some transition period. It is relatively easy to call str(p) whether p is a string or a path if you actually want a string.
On Wed, 26 Aug 2020 at 13:23, Christopher Barker firstname.lastname@example.org wrote:
On Thu, Aug 20, 2020 at 9:08 PM Ethan Furman email@example.com wrote:
But for a while is was painful to use, 'cause there was som much code that still used strings for paths. That was made a lot better when we introduced the __fspath__ protocol, and then updated the standard library to use it (everywhere?).
Unfortunately not . The __fspath__ protocol is supported in locations where a path is expected as an argument (e.g. os.path.join()); anywhere else it is not supported except by accident (meaning it could easily become actually unsupported in the future).
I guess this is why some folks though making PATH a subclass of str might be a good idea in the first place.
So a new idea (very poorly thought out) -- make a StrPath that is both a subclass of Path and a str -- so it could be used for things like __file__, and code that expects a string will still work, and code that expects a Path object will work as well. Since both Path and str are immutable, str methods would return strings, and Path methods would return Path objects.
I haven't looked for name clashes yet, but does this seem possible?
-- Christopher Barker, PhD
Python Language Consulting
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
Python-ideas mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://firstname.lastname@example.org/message/WB35LZ... Code of Conduct: http://python.org/psf/codeofconduct/