[Python-ideas] Binary f-strings

[Steve Dower]

Maybe we could spell it {spam!p:<10sHHb}?

Top-posted from my Windows Phone

-----Original Message-----
From: "Andrew Barnert" <abarnert at yahoo.com>
Sent: ‎10/‎3/‎2015 15:31
To: "Steve Dower" <steve.dower at python.org>
Cc: "Nick Coghlan" <ncoghlan at gmail.com>; "Guido van Rossum" <guido at python.org>; "Python-Ideas" <python-ideas at python.org>
Subject: Re: [Python-ideas] Binary f-strings

On Oct 3, 2015, at 09:20, Steve Dower <steve.dower at python.org> wrote:


"Something else that's neat with this: you could use the struct module
for more complex subsections of a binary protocol"

Personally, if binary f-strings did struct packing by default, I'd want to use them all the time.

bf'{header}{record:<10sHHb}{footer}'



I love that at first glance. But if the point of bf-strings (like the point of bytes.__mod__ and the other str-like stuff added back to bytes since 3.0) is for things like ascii-based, partly-human-readable protocols and formats, it's obviously important to do things like hex and octal, space- and zero-padding, etc., and if the format specifier always means struct, there's no way to do that.


Practically, if they aren't equivalent to removing the b and encoding the resulting f-string, I expect we'll regularly hit confusion and misunderstanding.



But removing the b and encoding the resulting f-string is useless. For example:


    header = b'Spam'
    value = 42
    lines.append(bf'{header}: {value}\r\n')


This gives you b"b'Spam': 42\r\n". Can you imagine ever wanting that?


The only way the feature makes sense is if it does something different.


Nick's suggestion of having it do %-formatting makes sense. Yes, it means that {count:03} is an error and you need '{count:03d}', which is inconsistent with f-strings. But that seems like a much less serious problem than bytes formatting not being able to handle bytes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151004/236fbe78/attachment.html>