This looks pretty good to me. I don't think we should limit
operands based on type, that's anti-Pythonic IMHO. We should use
duck-typing and that means a special method, I think. We could
introduce a new one but __bytes__ looks like it can work.
Otherwise, maybe __ascii__ is a good name.
Objects that implement __str__ can also implement __bytes__ if they
can guarantee that ASCII characters are always returned, no matter
what the *value* (we don't want to repeat the hell of Python 2's
unicode to str coercion which depends on the value of the unicode
object). Objects that already contain encoded bytes or arbitrary
bytes can also implement __bytes__.
Ethan Furman <et...@stoneleaf.us> wrote:
> %s, because it is the most general, has the most convoluted resolution:
This becomes much simpler:
- does the object implement __bytes__?
call it and use the value otherwise raise TypeError
> It has been suggested to use %b for bytes instead of %s.
>
> - Rejected as %b does not exist in Python 2.x %-interpolation, which is
> why we are using %s.
+1. %b might be conceptually neater but ease of migration trumps
that, IMHO.
> It has been proposed to automatically use .encode('ascii','strict') for str
> arguments to %s.
>
> - Rejected as this would lead to intermittent failures. Better to have the
> operation always fail so the trouble-spot can be correctly fixed.
Right. That would put us back in Python 2 unicode -> str coercion
hell.
Thanks for writing the PEP.
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
