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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
