16.01.2014 17:33, Michael Urman wrote:
> On Thu, Jan 16, 2014 at 8:45 AM, Brett Cannon <brett at 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
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