[Python-Dev] PEP 460 reboot and a bitter fight (original) (raw)

Glenn Linderman v+python at g.nevcal.com
Mon Jan 13 22:01:48 CET 2014

On 1/13/2014 5:06 AM, Nick Coghlan wrote:

I figured out tonight that it's only positioning ASCII interpolation as analternative to adding binary interpolation that I have a problem with. It isn't, because you lose the structural assurance that you haven't inadvertently introduced an assumption of ASCII compatibility when you didn't need to. However, interpolation support is a convenient enough interface that I can see a version thatonly supports ASCII compatible interpolation being an attractive nuisance that becomes a source of hard to detect and fix data corruption bugs (just like the str type in Python 2).

If we add both, my objections go away: people like me can use the Python 3 only formatb and formatbmap methods and be confident we haven't inadvertently introduced any assumptions regarding ASCII compatibility, while folks that know they're dealing with an ASCII compatible format can use the ASCII assuming versions that are designed to be source compatible with Python 2. If someone incorrectly uses format() or formatmap() when they should be using the pure binary versions, that's a trivial bug fix (adding the necessary "b", and perhaps some explicit encoding calls) rather than a major restructuring of the code. If they use mod-formatting, that's a slightly bigger fix, but still just switching to a different spelling of the formatting operation. Both use cases (binary only and ASCII compatible) get covered cleanly, and nobody has to lose out. Cheers, Nick.

As part of that, what about an alternate spelling of % to allow binary-only interpolation operations using the handy syntax of % ? Doesn't seem like / is defined for bytes or str on the LHS. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140113/4ad24f26/attachment.html>

More information about the Python-Dev mailing list