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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4