[Python-Dev] PEP 461 - Adding % and {} formatting to bytes (original) (raw)

Guido van Rossum guido at python.org
Wed Jan 15 19:39:27 CET 2014

All sounds good.

A fleeting thought about constructors: you can always add alternative constructors as class methods (like datetime does).

On Wed, Jan 15, 2014 at 10:09 AM, Neil Schemenauer <nas at arctrix.com> wrote:

Antoine Pitrou <solipsis at pitrou.net> wrote:

On Wed, 15 Jan 2014 15:47:43 +0000 (UTC) Neil S wrote:

Objects that implement str can also implement bytes if they can guarantee that ASCII characters are always returned, no matter what the value I think that's a slippery slope. bytes should mean that the object has a well-known bytes equivalent or encoding, not that its str happens to be pure ASCII. After poking around some more into the Python 3 source, I agree. It seems too late to change bytes() and bytearray(). We should have used a keyword only argument but too late now (tpnew is a mess). I can also agree that pushing the ASCII-centric behavior into the bytes() constructor goes too far. If we limit the ASCII-centric behavior solely to % and format(), that seems a reasonable trade-off for usability. As others have argued, once you are using format codes, you are pretty clearly dealing with ASCII encoding. I feel strongly that % and format on bytes needs to use duck-typing and not type checking. Also, formatting falures must be due to types and not due to values. If we can get agreement on these two principles, that will help guide the design. Those principles absolutely rule out call calling encode('ascii') automatically. I'm not deeply intimate with format() but I think it also rules out calling format. Could we introduce only bformat and have the % operator call it? That would only require implementing one new special method instead of two. Neil

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org

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

More information about the Python-Dev mailing list