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

[Daniel Delay]

Diez B. Roggisch a écrit :

> Apart from that, I don't think your proposal does any good - it is ugly 
> (or at least not less ugly than the things you want to fix) and confuses 
> the reader because of the colliding use of . for attribute access.

There is no ambiguity ( in one case "." is followed by a name, in 
another case it is followed by a parenthesis) but there is a similarity 
that I wanted and that I try here to illustrate :

#**********************
# Classical way : you need to evaluate
# something for few instances of a class
# so you write a mumber function
#**********************
class Rectangle :
	def area(self):
		return self.height * self.width
...
(... an expression....).area()

#**********************
# Alternative way : you need only once to evaluate something,
# and you work on a big expression
#**********************

(... an expression....).( this.height * this.width )	



But one of the advantages of this syntax is the ability to compose very 
easily those expressions :
(... an expression....).(..expr 1..).(..expr 2..).(..expr 3..) etc...



> 
> E.g.  your own example
> 
> f(g(h(j(x)))
> 
> becomes
> 
> x.(j(?)).(h(?)).(g(?)).(h(?))
> 
> Not x.(j).(h).(g).(h), as you told us. And certainly way uglier than the 
> above way of doing. Besides, you reasoning by comparing with the 
> mathematical o-operator is misleading: the operator creates a new 
> function, that will apply it's parametesr (e.g. f and g) after each 
> other to the argument. 

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

Paul Rubin asked for ways to do that, and has
> been shown some ways to do so - actually not overly nice looking, but 
> they'd allow for
> 
> (f * g * h)(x)
> 
> which beats your solution on readability, too :)

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.

> Overall, it tries to obfuscate code - by creating perl-like "magic" 
> variables. And that is not what Python is known for.

The wildcard "?" does does not sound very pythonic, but a few too magic. 
Perhaps a keyword like "this" is better, that's what I used in the above 
example.

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 too have some convoluted constructs as your html-joining example. But 
> if the get too complicated, replacing them by some explicit lines is 
> better than trying to cough up a scheme that makes them work.
> 
> Regards,
> 
> Diez