On 11.04.2016 23:15, Ethan Furman wrote: > We've pretty decided that we have two options: > > 1. remove pathlib > 2. make the stdlib work with pathlib > > So we're trying to make option 2 work before falling back to option 1. > > If you have a way to make pathlib work with the stdlib that doesn't > involve "fixing" os and os.path, now is the time to speak up. As I said, I don't like messing with os or os.path. They are built with a different level of abstraction in mind. What makes people want to go down from pathlib to os (speaking in terms of abstraction) is the fact that pathlib suggests/promise a convenience that it cannot hold. You might have seen my "feedback" post here on python-dev. If those points were corrected in a reasonable way, we wouldn't have had the need to go down to os or other stdlib modules. As it presents itself, it feels like a poor wrapper for os and os.path. I hope that makes sense. So, I might add: 3. add more high-level features to pathlib to prevent a downgrade to os or os.path Best, Sven
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