[Python-Dev] PEP 460 reboot and a bitter fight
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 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.
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...
More information about the Python-Dev