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

[Diez B. Roggisch]

> There's something i don't understand :
> 
> I've posted the original message you reply to yesterday, but I still 
> cannot see it in comp.lang.python, while I can see your reply, and my 
> reply to your reply.
> 
> I tried with two different providers to get the messages, but with the 
> same result.
> 
> Is it possible that this msg could have been throwned away by moderators 
> of this list ?? But in this case, you wouldn't have been able to read it...

It can be seen on gmane, but not with my news-reader.

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.

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. 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 :)


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

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