(original) (raw)

On Wed, 11 May 2016 at 14:29 Nikolaus Rath <Nikolaus@rath.org> wrote:

On May 11 2016, Brett Cannon <brett@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.