[Python-Dev] PEP 460: allowing %d and %f and mojibake (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Sun Jan 12 04:09:01 CET 2014
- Previous message: [Python-Dev] PEP 460: allowing %d and %f and mojibake
- Next message: [Python-Dev] PEP 460: allowing %d and %f and mojibake
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 numbers).
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.
Cheers, Nick.
For %s, the choice between string and number is made using "(PyLongCheck() || PyFloatCheck())". 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: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140112/9932a523/attachment.html>
- Previous message: [Python-Dev] PEP 460: allowing %d and %f and mojibake
- Next message: [Python-Dev] PEP 460: allowing %d and %f and mojibake
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]