[Python-Dev] file system path protocol PEP (original) (raw)
Ethan Furman ethan at stoneleaf.us
Wed May 11 17:52:54 EDT 2016
- Previous message (by thread): [Python-Dev] file system path protocol PEP
- Next message (by thread): [Python-Dev] file system path protocol PEP
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 05/11/2016 02:28 PM, Nikolaus Rath wrote:
On May 11 2016, Brett Cannon wrote:
This PEP proposes a protocol for classes which represent a file system path to be able to provide a
str
orbytes
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 astr
orbytes
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? If not, what's the crucial difference to file system paths?
I think a crucial reason for this work is to unify the stdlib: we currently have four (?) different things that can be or represent a file-system path:
- str
- bytes
- DirEntry
- Path
Half of those objects don't work well with the rest of the standard library.
As for your second example, the protocol already exists: it's called bytes. ;)
--
Ethan
- Previous message (by thread): [Python-Dev] file system path protocol PEP
- Next message (by thread): [Python-Dev] file system path protocol PEP
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]