(original) (raw)

On 15 Jan 2014 07:36, "Ethan Furman" <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> 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.

Cheers,
Nick.

>
\> Obviously we have int, float, and complex. �We also have Decimal.
\>
\> But what about Fraction? �Or some users numeric class that doesn't inherit from a core numeric type? �Wherever we draw the line, we need to make it's well-documented.
\>
\> --
\> \~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