Antoine Pitrou <solip...@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(<integer>) and bytearray(<integer>).
We should have used a keyword only argument but too late now (tp_new
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@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
