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.
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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4