[Python-Dev] PEP 461 - Adding % and {} formatting to bytes

[Jan Kaliszewski]

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