[Python-Dev] When should pathlib stop being provisional? (original) (raw)
Ethan Furman ethan at stoneleaf.us
Wed Apr 6 11:01:30 EDT 2016
- Previous message (by thread): [Python-Dev] When should pathlib stop being provisional?
- Next message (by thread): [Python-Dev] When should pathlib stop being provisional?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 04/06/2016 02:50 AM, Antoine Pitrou wrote:
Ethan Furman <ethan stoneleaf.us> writes:
Not sure about os.path.*. The purpose of os.path module is manipulating string paths. From the perspective of pathlib it can look lower level. The point is that a function that receives a "path" object (whether str or Path) shouldn't have to care: it should be able to call os.path.split on the thing it received and get back a usable answer. pathlib should already replicate the useful parts of os.path. That was the design goal after all.
Yes it does, and very well.
So this is like saying you want a Python file or socket object to be accepted by os.read(). In the rare case where you want that, you call the .fileno() method explicitly. The equivalent for Path objects is to lookup the .path attribute explicitly.
Unfortunately for Path objects there is already a well-established ecosystem for dealing with paths as strings, and it currently breaks when passed a Path path object. This is a high barrier to entry. Having the stdlib support Path objects would lower that barrier significantly.
--
Ethan
- Previous message (by thread): [Python-Dev] When should pathlib stop being provisional?
- Next message (by thread): [Python-Dev] When should pathlib stop being provisional?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]