[Python-Dev] PEP 460 reboot (original) (raw)

Eric V. Smith eric at trueblade.com
Tue Jan 14 21:04:48 CET 2014

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.

More information about the Python-Dev mailing list