On Tue, Jan 14, 2014 at 12:04 PM, Eric V. Smith <e...@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) _______________________________________________ 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
