On 4 October 2015 at 08:25, Andrew Barnert <abarnert@yahoo.com> wrote:
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.
Exactly, if someone is mistakenly thinking bf"{header}{content}{footer}" is equivalent to f"{header}{content}{footer}".encode(), they're likely to get immediate noisy errors when they start trying to format fields. The parallel I'd attempt to draw is that: f"{header}{content}{footer}" is to "{}{}{}".format(header, content, footer) as: bf"{header:b}{content:b}{footer:b}" would be to b"%b%b%b" % (header, content, footer) To make the behaviour clearer in the latter case, it may be reasonable to *require* an explicit field format code, since that corresponds more closely to the mandatory field format codes in mod-formatting. I'm not sold on the idea of a struct.pack conversion specifier - if we added binary format strings, I think it would be better to start with explicit "pack(value, format)" expressions, and see how that goes for a release. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia