On Wed, 11 May 2016 at 14:29 Nikolaus Rath <Nikolaus at rath.org> wrote: > On May 11 2016, Brett Cannon <brett at python.org> wrote: > > This PEP proposes a protocol for classes which represent a file system > > path to be able to provide a ``str`` or ``bytes`` representation. > [...] > > As I said before, to me this seems like a lot of effort for a very > specific use-case. So let me put forward two hypothetical scenarios to > better understand your position: > > - A new module for URL handling is added to the standard library (or > urllib is suitably extended). There is a proposal to add a new > protocol that allows classes to provide a ``str`` or ``bytes`` > representation of URLs. > > - A new (third-party) library for natural language processing arises > that exposes a specific class for representing audio data. Existing > language processing code just uses bytes objects. To ease transition > and interoperability, it is proposed to add a new protocol for classes > that represend audio data to provide a bytes representation. > > Do you think you would you be in favor of adding these protocols to > the stdlib/languange reference as well? Maybe for URLs, not for audio data (at least not in the stdlib; community can do what they want). > If not, what's the crucial > difference to file system paths? > Nearly everyone uses file system paths on a regular basis, less so than URLs but still a good amount of people. Very few people work with audio data. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160511/a7c8fc19/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