On 12.05.2016 00:13, Brett Cannon wrote: > I see this whole discussion breaking down into a few groups which > changes what gets done upfront and what might be done farther down the > line: > > 1. Maximum acceptance: do whatever we can to make all representation > of paths just work, which means making all places working with a > path in the stdlib accept path objects, str, and bytes. > 2. Safely use path objects: __fspath__() is there to signal an object > is a file system path and to get back a lower-level representation > so people stop calling str() on everything, providing some > interface signaling that someone doesn't misuse an object as a > path and only changing path consumptions APIs -- e.g. open() -- > and not path manipulation APIs -- e.g. os.path -- in the stdlib. > 3. It ain't worth it: those that would rather just skip all of this > and drop pathlib from the stdlib. > Sorry for being picky here. I think the last group needs to be split up: 3. It ain't worth it: those that would rather just skip all of this 4. drop pathlib from the stdlib. I put myself into camp 3, mostly because I don't consider the "wallet garden problem" a problem at all and I realized that our past issues with pathlib resulted from missing features in pathlib not in the rest of the stdlib. Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160512/877fa176/attachment.html>
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