[Python-Dev] PEP 461 - Adding % and {} formatting to bytes (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Tue Jan 14 23:38:11 CET 2014
- Previous message: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes
- Next message: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 15 Jan 2014 08:23, "Ethan Furman" <ethan at stoneleaf.us> wrote:
On 01/14/2014 02:17 PM, Nick Coghlan wrote:
_On 15 Jan 2014 07:36, "Ethan Furman" <ethan at stoneleaf.us <mailto:_ ethan at 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 at stoneleaf.us <mailto:ethan at 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 Pybuffer instead. Meaning any bytes or bytes-subtype will support the Pybuffer 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 Pybuffer 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 at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140115/189d85a8/attachment-0001.html>
- Previous message: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes
- Next message: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]