On Apr 18, 2016 2:50 PM, "Ethan Furman" <ethan at stoneleaf.us> wrote: > > On 04/18/2016 12:25 PM, Stephen J. Turnbull wrote: > >> Koos Zevenhoven writes: > > >>> After all, we want something that's *almost* exclusively str. >> >> >> But we don't want that, AFAICT. Some clearly want this API to be >> unbiased against bytes in the same way the os APIs are unbiased[2], >> because that's what we've got in the current proposal. > > > Are we reading the same thread? For my last several replies I am very biased against bytes (and I know I'm not the only one). > > Just not so biased that I'm unwilling to let clients say, "No, I'm really okay with getting bytes back". > > I really like Koos' ideas because they allow the client to say: > > - I only want str > - I only want bytes > - I'm okay with either > > If the client says "I'm okay with either" then I fully expect the client to have code to properly handle str vs bytes after the fspath (or whatever it's called) call. Don't we *have* to always support bytes because other programs can create filenames containing bytes? > > -- > ~Ethan~ > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160418/d4dc7909/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