On 12 Jan 2014 03:44, "Victor Stinner" <victor.stin...@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 > "(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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
