[Python-Dev] Binary Operator for New-Style String Formatting

[Jerry Chen]

Ah, the people have spoken!

On Sun, Jun 21, 2009 at 2:12 PM, Terry Reedy<tjreedy at 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