Maybe we could spell it {spam!p:<10sHHb}? Top-posted from my Windows Phone -----Original Message----- From: "Andrew Barnert" <abarnert@yahoo.com> Sent: 10/3/2015 15:31 To: "Steve Dower" <steve.dower@python.org> Cc: "Nick Coghlan" <ncoghlan@gmail.com>; "Guido van Rossum" <guido@python.org>; "Python-Ideas" <python-ideas@python.org> Subject: Re: [Python-ideas] Binary f-strings On Oct 3, 2015, at 09:20, Steve Dower <steve.dower@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.