16.01.2014 17:33, Michael Urman wrote:
On Thu, Jan 16, 2014 at 8:45 AM, Brett Cannon <br...@python.org>
wrote:
Fine, if you're worried about bytes.format() overstepping by
implicitly
calling str.encode() on the return value of __format__() then you
will need
__bytes__format__() to get equivalent support.
Could we just re-use PEP-3101's note (easily updated for Python 3):
Note for Python 2.x: The 'format_spec' argument will be either
a string object or a unicode object, depending on the type of the
original format string. The __format__ method should test the
type
of the specifiers parameter to determine whether to return a
string or
unicode object. It is the responsibility of the __format__
method
to return an object of the proper type.
If __format__ receives a format_spec of type bytes, it should return
bytes. For such cases on objects that cannot support bytes (i.e. for
str), it can raise. This appears to avoid the need for additional
methods. (As does Nick's proposal of leaving it out for now.)
-1.
I'd treat the format()+.__format__()+str.format()-"ecosystem" as
a nice text-data-oriented, *complete* Py3k feature, backported to
Python 2 to share the benefits of the feature with it as well as
to make the 2-to-3 transition a bit easier.
IMHO, the PEP-3101's note cited above just describes a workaround
over the flaws of the Py2's obsolete text model. Moving such
complications into Py3k would make the feature (and especially the
ability to implement your own .__format__()) harder to understand
and make use of -- for little profit.
Such a move is not needed for compatibility. And, IMHO, the
format()/__format__()/str.format()-matter is all about nice and
flexible *text* formatting, not about binary data interpolation.
16.01.2014 10:56, Nick Coghlan wrote:
I have a different proposal: let's *just* add mod formatting to
bytes, and leave the extensible formatting system as a text only
operation.
We don't really care if bytes supports that method for version
compatibility purposes, and the deliberate flexibility of the design
makes it hard to translate into the binary domain.
So let's just not provide that - let's accept that, for the binary
domain, printf style formatting is just a better fit for the job :)
+1!
However, I am not sure if %s should be limited to bytes-like
objects. As "practicality beats purity", I would be +0.5 for
enabling the following:
- input type supports Py_buffer?
use it to collect the necessary bytes
- input type has the __bytes__() method?
use it to collect the necessary bytes
- input type has the encode() method?
raise TypeError
- otherwise:
use something equivalent to ascii(obj).encode('ascii')
(note that it would nicely format numbers + format other
object in more-or-less useful way without the fear of
encountering a non-ascii data).
another option: use str()-representation of strictly
defined types, e.g.: int, float, decimal.Decimal,
fractions.Fraction...
Cheers.
*j
_______________________________________________
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
