On 1/13/2014 5:06 AM, Nick Coghlan wrote:
I figured out tonight that it's only positioning ASCII interpolation
as an*alternative* 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 that*only*
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 formatb_map 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 format_map() 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.
_______________________________________________
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
