Nick Coghlan writes: > The gist of the motivation for bytes/str polymorphism here is similar to > that for restoring __mod__ polymorphism in > https://www.python.org/dev/peps/pep-0461/:
I don't think it is, actually. Filenames off the wire cannot be relied on to be in the local file system encoding, and that matters. The semantics of a filename or path requires getting the encodings matched. You cannot be encoding-agnostic. On the other hand, streams of characters are merely a special case of streams of tokens, and the principles that apply to editing streams of characters apply to more general tokens, including bytes and XML. You *can* be content-agnostic as long as you define semantics in terms of moving tokens around, and not in terms of their content. BTW, my opposition to PEP 461 was based on the same mistake with opposite polarity: I think of bytes as encoded text *first*, and therefore feared PEP 461 for quite insufficient reason. Most applications of PEP 461 won't be for text. > This is also why I ended up proposing pushing the complexity down into a > documented-but-underscore-prefixed API: folks writing pure Python 3 > application code *really* shouldn't need to worry about the bytes > support You can't have that with your proposal. They are going to (at least in theory) get a new TypeError which they will not be expecting (vs bytes, which are implicit in the object they have, where previously they would have got one vs. Path or DirEntry which they were expecting). So they will have to learn that much about bytes support. > in the protocol, but for operating system level use cases, not having it > readily available to 2/3 compatible Python code would be a pain. Erm, how do you propose to make this protocol available to Python-2- compatible code? Pervasively monkey-patch the Python 2 os module? Even if so, is it our responsibility to worry about that? BTW, I came to this conclusion thinking about the poster boy for PEP 461, Mercurial. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
