still more use for pathlib.Path ....
I really like pathlib. 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?). But there are still a few that bug me. For instance: __file__ is a path represented as a string. It's not too big a deal to wrap it in Path(), but it still annoys me. So: would it be entirely too disruptive to replace these kinds of things with Path objects? -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
What about code that depends on __file__ to add installation dependent import paths to sys.path? I have written code like that myself, and I've seen it elsewhere too. --Edwin On 8/20/2020 9:06 PM, Christopher Barker wrote:
I really like pathlib.
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?).
But there are still a few that bug me. For instance:
__file__ is a path represented as a string. It's not too big a deal to wrap it in Path(), but it still annoys me.
So: would it be entirely too disruptive to replace these kinds of things with Path objects?
-CHB
-- Christopher Barker, PhD
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GIKHET... Code of Conduct: http://python.org/psf/codeofconduct/
For the specific case of `__file__`, yes, I think that would be too disruptive. This isn't a function that *consumes* a path -- it's a path that is consumed by innumerable other modules, most of which aren't under active maintenance, and a sizable fraction of those would break if this turned into a Path. For other situations, you'd have to get specific -- I can't guess which ones particularly bug you. :-) On Thu, Aug 20, 2020 at 6:07 PM Christopher Barker <pythonchb@gmail.com> wrote:
I really like pathlib.
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?).
But there are still a few that bug me. For instance:
__file__ is a path represented as a string. It's not too big a deal to wrap it in Path(), but it still annoys me.
So: would it be entirely too disruptive to replace these kinds of things with Path objects?
-CHB
-- Christopher Barker, PhD
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GIKHET... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
I have no idea how hard/bad/maintenance heavy this would be, but wouldn't the easy way be simply to provide another attribute (e.g. __path__) with what you want and maintain __file__? I've never used a Path object (directly), I feel like I'm missing out now! On Fri, 21 Aug 2020 at 02:09, Christopher Barker <pythonchb@gmail.com> wrote:
I really like pathlib.
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?).
But there are still a few that bug me. For instance:
__file__ is a path represented as a string. It's not too big a deal to wrap it in Path(), but it still annoys me.
So: would it be entirely too disruptive to replace these kinds of things with Path objects?
-CHB
-- Christopher Barker, PhD
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GIKHET... Code of Conduct: http://python.org/psf/codeofconduct/
On 8/20/20 6:06 PM, Christopher Barker 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 [1]. 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). -- ~Ethan~ [1] https://bugs.python.org/issue39461
On Thu, Aug 20, 2020 at 9:08 PM Ethan Furman <ethan@stoneleaf.us> 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 [1]. 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? -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
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 <pythonchb@gmail.com> wrote:
On Thu, Aug 20, 2020 at 9:08 PM Ethan Furman <ethan@stoneleaf.us> 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 [1]. 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?
-CHB
-- Christopher Barker, PhD
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WB35LZ... Code of Conduct: http://python.org/psf/codeofconduct/
participants (6)
-
Christopher Barker -
Edwin Zimmerman -
Ethan Furman -
Guido van Rossum -
Henk-Jaap Wagenaar -
Matthias Bussonnier