(original) (raw)

On 15 Jan 2014 08:23, "Ethan Furman" <ethan@stoneleaf.us> wrote:
\>
\> On 01/14/2014 02:17 PM, Nick Coghlan wrote:
\>>
\>>
\>> On 15 Jan 2014 07:36, "Ethan Furman" <ethan@stoneleaf.us ethan@stoneleaf.us>> wrote:
\>>>
\>>>
\>>> On 01/14/2014 12:57 PM, Antoine Pitrou wrote:
\>>>>
\>>>>
\>>>> On Tue, 14 Jan 2014 11:56:25 -0800
\>>>> Ethan Furman <ethan@stoneleaf.us ethan@stoneleaf.us>> wrote:
\>>>>>
\>>>>>
\>>>>>
\>>>>> %s, because it is the most general, has the most convoluted resolution:
\>>>>>
\>>>>> � � - input type is bytes?
\>>>>> � � � pass it straight through
\>>>>
\>>>>
\>>>>
\>>>> It should try to get a Py\_buffer instead.
\>>>
\>>>
\>>>
\>>> Meaning any bytes or bytes-subtype will support the Py\_buffer protocol, and this should be the first thing we try?
\>>>
\>>> Sounds good.
\>>>
\>>> For that matter, should the first test be "does this object support Py\_buffer" and not worry about it being isinstance(obj, bytes)?
\>>
\>>
\>> Yep. I actually suggest adjusting the %s handling to:
\>>
\>> - interpolate Py\_buffer exporters directly
\>> - interpolate \_\_bytes\_\_ if defined
\>> - reject anything with an "encode" method
\>> - otherwise interpolate str(obj).encode("ascii")
\>>
\>>>>> � � - input type is numeric?
\>>>>> � � � use its \_\_xxx\_\_ \[1\] \[2\] method and ascii-encode it (strictly)
\>>>>
\>>>>
\>>>>
\>>>> What is the definition of "numeric"?
\>>>
\>>>
\>>>
\>>> That is a key question.
\>>
\>>
\>> As suggested above, I would flip the question and explicitly \*disallow\* implicit encoding of any object with its own
\>> "encode" method, while allowing everything else.
\>
\>
\> 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.
\>
\> 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\_\_.

Yeah, reading the other thread pointed out the issues with this idea (containers in particular are a problem).

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.

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.

Cheers,
Nick.

>
\>
\> --
\> \~Ethan\~
\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\> 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/ncoghlan%40gmail.com