New Python 3.0 string formatting - really necessary?

[Aaron Brady]

On Dec 21, 7:34 am, Marc 'BlackJack' Rintsch <bj_... at gmx.net> wrote:
> On Sun, 21 Dec 2008 12:45:32 +0000, Duncan Booth wrote:
> > You seem to have made an unwarranted assumption, namely that a binary
> > operator has to compile to a function with two operands. There is no
> > particular reason why this has to always be the case: for example, I
> > believe that C# when given several strings to add together optimises
> > this into a single call to a concatenation method.
>
> > Python *could* do something similar if the appropriate opcodes/methods
> > supported more than two arguments:
>
> > a+b+c+d might execute a.__add__(b,c,d) allowing more efficient string
> > concatenations or matrix operations, and a%b%c%d might execute as
> > a.__mod__(b,c,d).
>
> But that needs special casing strings and ``%`` in the comiler, because
> it might not be always safe to do this on arbitrary objects.  Only in
> cases where the type of `a` is known at compile time and ``a % b``
> returns an object of ``type(a)``.

'x+y' makes no guarantees whatsoever.  It could return an object of
type(x), type(y), or neither.  'a%b' in the case of strings is just,
str.__mod__, returning string.

In a+b+c, 'a' gets dibs over what the rest see, so there's no more
danger in the multi-ary case, than in binary; and that hasn't stopped
us before.

You might be confusing the cases of arbitrary operators vs. uniform
operators.  'a' does not get dibs in 'a+b*c'; 'b*c' are allowed to
carry out their affairs.  But in 'a+b+c', 'a*b*c', 'a%b%c', and so on,
'a' has final say on b's and c's behaviors via its return value, so
loses nothing by combining such a call.

In short, you can force it anyway, so it's syntactic sugar after that.