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 <n...@arctrix.com> wrote:
> 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/guido%40python.org
--
--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
