[Python-Dev] PEP 460: allowing %d and %f and mojibake

Mark Lawrence breamoreboy at yahoo.co.uk
Sun Jan 12 23:32:06 CET 2014

On 12/01/2014 17:03, Ethan Furman wrote:
> 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.

I've just tried asciistr using your test code (having corrected the 
typo, it's assertIsInstance, not assertIsinstance :) and it looks like a 
very good starting point.  Have you, or anyone else for that matter, 
actually tried asciistr out?

> --
> ~Ethan~
> [1] https://github.com/jeamland/asciicompat
> [2] the dbf and pdf folks, at least

My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

More information about the Python-Dev mailing list