[Python-Dev] PEP 460 reboot

[Eric V. Smith]

On 01/14/2014 01:52 PM, Guido van Rossum wrote:

> But the way to arrive at this behavior without duplicating a whole lot
> of code seems to be to call the existing text-based __format__ API and
> convert the result to bytes -- for numbers this should be safe (their
> formatting produces just ASCII digits and a selected few other ASCII
> characters) but leads to an undesirable outcome for other types -- not
> just str but also e.g. lists or dicts containing str instances, since
> those call __repr__ on the contained items, and repr() may produce
> non-ASCII bytes.

That's why I suggested restricting the types supported. If we could live
with just a subset of known types, then we could hard-code the
conversions to bytes. How many types with custom __format__'s are really
getting written to byte strings in 2.x? For that matter, are any lists,
sets, or dicts (or anything else using object.__format__'s conversion
using str()) really getting written to bytes? Do we need to support
these cases?

In my mind, this comes down to: are we trying to add this just to make
porting easier? In my mind, we wouldn't even be adding feature at all
except for ease of porting 2.x code. So we should focus on what features
are used in the code we're trying to port. I don't think our focus is on
2.x code that's using u''.format(), it's 2.x code that's been reviewed
and is still using b''.format() because it's building up bytes for a
wire protocol. And that code is not likely to need to format objects
with arbitrary __format__ methods, or even str (in the 3.x sense). It's
only likely to use numbers and bytes (or str in the 2.x sense).

Eric.