Ah, the people have spoken! On Sun, Jun 21, 2009 at 2:12 PM, Terry Reedy<tjreedy@udel.edu> wrote:
The place to float trial balloons is the python-ideas list.
I'll put this one to rest, and as mentioned, will direct any future suggestions to python-ideas instead of here. Most of the arguments against my proposal state there is little gain and much to lose (in terms of clarity or an "obvious way" to go about string formatting) -- and, I agree.
The only advantage '@' over '.format' is fewer characters. I think it would be more useful to agitate to give 'format' a one char synonym such as 'f'.
str.f() would be a great idea.
One disadvantage of using an actual tuple rather than an arg quasi-tuple is that people would have to remember the trailing comma when printing one thing. '{}' @ (1,) rather than '{}' @ (a) == '{}' @ a. [If you say, 'Oh, then accept the latter', then there is a problem when a is a tuple!]
My code transforms both '{}' @ (a) and '{}' @ a to '{}'.format(a), but the problem you speak of is probably an edge case I haven't quite wrapped my head around. For what it's worth, I spent a bit of time trying to work out the syntactical quirks, including adapting the format tests in Lib/test/test_unicode.py to this syntax and ensuring all the tests passed. In the end though, it seems to be an issue of usability and clarity.
Formatting is inherently an n-ary function who args are one format and an indefinite number of objects to plug in. Packaging the remaining args into an object to convert the function to binary is problematical, especially in Python with its mix of positional and named args. Even without that, there is possible confusion between a package as an arg in itself and a package as a container of multiple args. The % formatting problem with tuple puns was one of the reasons to seek a replacement.
Also (from R. David Murray):
That said, I'm -1 on it. The 'keywords as last item of tuple' reeks of code-smell to my nose, and I don't think you've addressed all of the reasons for why a method was chosen over an operator. Python has a tradition of having "one obvious way" to do something, so introducing an "alternative" syntax that you admit is sub-optimal does not seem to me to have enough benefit to justify breaking that design guideline.
Well stated (and everyone else). Just one last note: I think my end goal here was to preserve the visual clarity and separation between format string and format parameters, as I much prefer: "%s %s %s" % (1, 2, 3) over "{0} {1} {2}".format(1, 2, 3) The former is a style I've grown accustomed to, and if % is indeed being slated for removal in Python 3.2, then I will miss it sorely (or... just get over it). Thanks to everyone who has provided constructive criticism and great arguments. Cheers, -- Jerry Chen