On 01/12/2014 08:21 AM, Ethan Furman wrote:
On 01/12/2014 08:09 AM, Nick Coghlan wrote:
On 13 Jan 2014 01:22, "Kristján Valur Jónsson" wrote:
Imho, this is not equivalent to re-introducing automatic type conversion
between binary/unicode, it is adding a
specific convenience function for explicitly asking for ASCII encoding.
It is not explicit, it is implicit - whether or not the resulting string
assumes ASCII compatibility or not depends on
whether you pass a binary value (no assumption) or a string value (assumes
ASCII compatibility).
Nick, I don't understand what you are saying here. Are you saying that the
result of b'%s' % var may be either a bytes
object or a str object? Because that would be wrong -- it would always be a
bytes object.
Okay, I just went and took a closer look at the asciistr type [1]. For what it's worth I don't think this is Antoine's
understanding of what we [2] are asking for, nor is it what we are asking for (I'm sure Antoine will correct me if I'm
wrong. ;)
We know full well the difference between unicode and bytes, and we know full well that numbers and much of the text we
need has an ASCII (bytes!) representation. When we do a b'Content Length: %d' % len(binary_data) we are expecting to
get back a bytes object, /not/ a unicode object.
Your asciistr, which sometimes returns bytes and sometimes returns text, is
absolutely *not* what we want.
--
~Ethan~
[1] https://github.com/jeamland/asciicompat
[2] the dbf and pdf folks, at least
_______________________________________________
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
