What about letting x.( ... ? ... ) be equivalent to ( ... x ... )

Diez B. Roggisch deets at web.de
Mon Oct 10 15:32:31 CEST 2005

Daniel Delay wrote:
> I agree the comparison to the mathematical o-operator is misleading, it
> was just to say sometimes, it can be usefull introduce new syntax to
> avoid too many nested parenthesis

To replace them by the same amount of parentheses with a dot in front?
Not very convincing.

> This is usefull when you need to compose few already defined functions,
> but I more often have to compose few expressions, which is the goal of
> my proposition.

The only reason this _could_ be preferable was in a situation where one
large expression contains several subexpressions that are supposed to
be the same value. Like this:

foo.join(bar.split()+ bar.split())

Then your prosal would make it

bar.split().(foo.join(? + ?))

But then again, this is by no means better to read. The only
justification is that you want to avoid the possibly costly double
evaluation of the common subexpression. But then, the critic of e.g.
Frederik applies: Why don't you do

a = bar.split()
foo.join(a + a)

Beats everything else in readability.

> In fact it has nothing to do with magical expression : "this" will
> represent the value of the current expression you work on, in the same
> way "self" represent the value of the object you work on.

I very well understand that. But I think the only thing it leads to is
more convoluted code. Which one wants to avoid.

More information about the Python-list mailing list