(original) (raw)

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.