[Python-Dev] PEP 460: allowing %d and %f and mojibake

Nick Coghlan ncoghlan at gmail.com
Sun Jan 12 04:09:01 CET 2014

On 12 Jan 2014 03:44, "Victor Stinner" <victor.stinner at gmail.com> wrote:
> Hi,
> I'm in favor of adding support of formatting integer and floatting
> point numbers in the PEP 460: %d, %u, %o, %x, %f with padding and
> precision (%10d, %010d, %1.5f) and sign (%-i, %+i) but without
> alternate format ("{:#x}"). %s would also accept int and float for
> convenience.
> int and float subclasses would not be handled differently, their
> __str__ and __format__ would be ignored.
> Other int-like and float-like types (ex: defining __int__ or
> __index__) are not supported. Explicit cast would be required.

asciistr will support the *full* text formatting API, so I don't see any
reason to add this complexity to the core bytes type. However, I like the
basic binary interpolation feature proposed by the current version of the
PEP - it's a nice convenience method that doesn't compromise the text model
by introducing implicit serialisation of other types (whether text or

For Python 2 folks trying to grok where the "bright line" is in terms of
the Python 3 text model: if your proposal includes *any* kind of implicit
serialisation of non binary data to binary, it is going to be rejected as
an addition to the core bytes type. If it avoids crossing that line (as the
buffer-API-only version of PEP 460 does), then we can talk.

Folks that want implicit serialisation (and I agree it has its uses) should
go help Benno get asciistr up to speed.


> For %s, the choice between string and number is made using
> "(PyLong_Check() || PyFloat_Check())".
> If you agree, I will modify the PEP. If Antoine disagree, I will fork
> the PEP 460 ;-)
> ---
> %s should not support precision (ex: %.100s), use Unicode for that.
> ---
> The PEP 460 should not reintroduce bytes+unicode, implicit decoding or
> implement encoding.
> b'x=%s' % 10 is well defined, it's pure bytes. If you consider that
> bytes should not contain text, why does the bytes type have methods
> like isalpha() or upper()? And why binary files have a readline()
> method? A "line" doesn't mean anything in pure bytes.
> It's an example of "practicality beats purity". Python 3 should not
> enforce Unicode if the developers *chose* to use bytes to handle mixed
> binary/text protocols like HTTP.
> But I'm against of adding "%r" and "%a" because they use Unicode and
> would require an implicit encoding. type(ascii(obj)) is str, not
> bytes. If you really want to use repr() and ascii(), encode the result
> explicitly.
> Victor
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140112/9932a523/attachment.html>

More information about the Python-Dev mailing list