[Python-3000] Please don't kill the % operator...

Fri Aug 17 17:37:52 CEST 2007

Eric Smith wrote:
> Ron Adam wrote:
>>>> Martin v. Lo"wis wrote:
>>> Bill Janssen schrieb:
>>>>> I think most of these points are irrelevant. The curly braces are not
>>>>> just syntactic sugar, at least the opening brace is not; the digit
>>>>> is not syntactic sugar in the case of message translations.
>>>> Are there "computation of matching braces" problems here?
>>> I don't understand: AFAIK, the braces don't nest, so the closing
>>> brace just marks the end of the place holder (which in the printf
>>> format is defined by the type letter).
>>> So expressions like the following might be difficult to spell.
>>>> '{{foo}{bar}}'.format(foo='FOO', bar='BAR', FOOBAR = "Fred")
>>>> This would probably produce an unmatched brace error on the first '}'.
>> Ah, I see. I hadn't thought of that case. You're correct, it gives an 
> error on the first '}'. This is a case where allowing whitespace would 
> solve the problem, sort of like C++'s "< <" template issue (which I 
> think they've since addressed). I'm not sure if it's worth doing, though:
>> '{ {foo}{bar} }'.format(foo='FOO', bar='BAR', FOOBAR = "Fred")
>> On second thought, that won't work. For example, this currently doesn't 
> work:
> '{0[{foo}{bar}]}'.format({'FOOBAR': 'abc'}, foo='FOO', bar='BAR')
> KeyError: 'FOO'
>> I can't decide if that's a bug or not.

I think it will be a bug. Some one is bound to run into it at some point 
if they are using nested braces routinely. Although most people never 
will, so it may be a limitation we can live with.
White space will only work on the name side, not the specifier side of the 
colon as it's significant on that side.
_RON