[Python-Dev] PEP 460 reboot

[Guido van Rossum]

On Tue, Jan 14, 2014 at 12:04 PM, Eric V. Smith <eric at trueblade.com> wrote:
> 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).

Yes, these are exactly the right questions to ask.

-- 
--Guido van Rossum (python.org/~guido)