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

Ron Adam rrr at ronadam.com
Fri Aug 17 07:49:33 CEST 2007



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

They can nest.  See these tests that Eric posted earlier, second example.

Eric Smith wrote:
> These tests all pass:
> 
> self.assertEquals('{0[{1}]}'.format('abcdefg', 4), 'e')
> self.assertEquals('{foo[{bar}]}'.format(foo='abcdefg', bar=4), 'e')
> self.assertEqual("My name is {0}".format('Fred'), "My name is Fred")
> self.assertEqual("My name is {0[name]}".format(dict(name='Fred')),
>                   "My name is Fred")
> self.assertEqual("My name is {0} :-{{}}".format('Fred'),
>                   "My name is Fred :-{}")


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


>>> That lots of people are familiar with the old format and only few are
>>> with the new is merely a matter of time.
>> Sure, but the problem is that there are a lot of Python programmers
>> *now* and learning the new syntax imposes a burden on all of *them*.
>> Who cares how many people know the syntax in the future?
> 
> That is the problem of any change, right? People know the current
> language; they don't know the changed language. Still, there are
> conditions when change is "allowed".
> 
> For example, the syntax of the except clause changes in Py3k, replacing
> the comma with "as"; this is also a burden for all Python programmers,
> yet the change has been made.
> 
>>> That the new format is more verbose than the old one is true, but only
>>> slightly so - typing .format is actually easier for me than typing
>>> % (which requires a shift key).
>> I don't mind the switch to ".format"; it's the formatting codes that I
>> don't want to see changed.
> 
> Ok. For these, the "more verbose" argument holds even less: in the most
> simple case, it's just one character more verbose per placeholder.

I think having more verbose syntax is a matter of trade offs.  I don't mind 
one or two characters if it saves me from writing 20 or 30 someplace else.

Such is the case if you can't do something in the format string, it means 
you need to do it someplace else that will often take up a few lines rather 
than a few characters.

_RON



More information about the Python-3000 mailing list