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

[Ron Adam]

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