Showing content from http://mail.python.org/pipermail/python-dev/attachments/20140115/189d85a8/attachment-0001.html below:
<p dir="ltr"><br>
On 15 Jan 2014 08:23, "Ethan Furman" <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br>
><br>
> On 01/14/2014 02:17 PM, Nick Coghlan wrote:<br>
>><br>
>><br>
>> On 15 Jan 2014 07:36, "Ethan Furman" <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a> <mailto:<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>>> wrote:<br>
>>><br>
>>><br>
>>> On 01/14/2014 12:57 PM, Antoine Pitrou wrote:<br>
>>>><br>
>>>><br>
>>>> On Tue, 14 Jan 2014 11:56:25 -0800<br>
>>>> Ethan Furman <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a> <mailto:<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>>> wrote:<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> %s, because it is the most general, has the most convoluted resolution:<br>
>>>>><br>
>>>>> - input type is bytes?<br>
>>>>> pass it straight through<br>
>>>><br>
>>>><br>
>>>><br>
>>>> It should try to get a Py_buffer instead.<br>
>>><br>
>>><br>
>>><br>
>>> Meaning any bytes or bytes-subtype will support the Py_buffer protocol, and this should be the first thing we try?<br>
>>><br>
>>> Sounds good.<br>
>>><br>
>>> For that matter, should the first test be "does this object support Py_buffer" and not worry about it being isinstance(obj, bytes)?<br>
>><br>
>><br>
>> Yep. I actually suggest adjusting the %s handling to:<br>
>><br>
>> - interpolate Py_buffer exporters directly<br>
>> - interpolate __bytes__ if defined<br>
>> - reject anything with an "encode" method<br>
>> - otherwise interpolate str(obj).encode("ascii")<br>
>><br>
>>>>> - input type is numeric?<br>
>>>>> use its __xxx__ [1] [2] method and ascii-encode it (strictly)<br>
>>>><br>
>>>><br>
>>>><br>
>>>> What is the definition of "numeric"?<br>
>>><br>
>>><br>
>>><br>
>>> That is a key question.<br>
>><br>
>><br>
>> As suggested above, I would flip the question and explicitly *disallow* implicit encoding of any object with its own<br>
>> "encode" method, while allowing everything else.<br>
><br>
><br>
> Um, int and floats (for example) don't have an .encode method, don't export Py_buffer, don't have a __bytes__ method... Ah! so it would hit the last case, I see.<br>
><br>
> The danger I see with that route is that any ol' object could then make it into the byte stream, and considering what byte streams are for I think we should make the barrier for entry higher than just relying on a __str__ or __repr__.</p>
<p dir="ltr">Yeah, reading the other thread pointed out the issues with this idea (containers in particular are a problem).</p>
<p dir="ltr">I think Brett has the right idea: we shouldn't try to accept numbers for %s in binary interpolation. If we limit it to just buffer exporters and objects with a __bytes__ method then the problem goes away.</p>
<p dir="ltr">The numeric codes all exist in Python 2, so the porting requirement to the common 2/3 subset will be to update the cases of binary interpolation of a number with %s to use an appropriate numeric formatting code instead.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
><br>
> --<br>
> ~Ethan~<br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>
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