On Oct 7, 2015, at 04:35, Nick Coghlan <ncoghlan@gmail.com> wrote:
>
>> 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.

Except that multiple people in this thread are saying that'd exactly what it should mean (which I think is a very bad idea).

> 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.

Are you suggestive that if a format specifier is given, it must include the format code (which seems perfectly reasonable to me--guessing that :3 means %3b is likely to be wrong more often than it's right…), or that a format specifier must always be given, with no default to :b (which seems more obtrusive and solves less of a problem).