On 04/06/2016 02:50 AM, Antoine Pitrou wrote: > Ethan Furman <ethan <at> 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~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4