On Tue, Jul 20, 2010 at 8:32 PM, Sturla Molden firstname.lastname@example.org wrote:
Den 20.07.2010 20:56, skrev Alex Light:
i would suggest overloading the 'with', 'as' combo
c = sqrt(a*a + b*b) with: get_a(), get_b() as a, b
That will not work, the parser would think like this:
c = sqrt(a*a + b*b) with: get_a(), (get_b() as a), b
Not true, we can define the grouping as we like. However if we do something like this I'd rather use 'var = expr' instead of 'expr as var'.
c = sqrt(a*a + b*b) with: get_a() as a get_b() as b
I think it tastes too much like functional programming. Specifically:
It forces you to think backwards: it does not evaluate the lines in the order they read. The block below is evaluated before the expression above. It really means:
a = get_a() b = get_b() c = sqrt(a*a + b*b) with: del a,b
That I think is very annoying.
Like it or not, except for the keyword to use and the 'as' issue, that's exactly the proposal (please read the PEP: http://www.python.org/dev/peps/pep-3150/ ).
I personally like it; plus the "think backwards" idea is already used in other parts of Python' syntax, e.g. list comprehensions. And of course forward references work for method calls too.
Why not just use context managers instead?
with get_a() as a, get_b() as b: c = sqrt(a*a + b*b)
Now it reads the right way: top down, not bottom up.
Because this means something different and requires that get_a() return something that obeys the context manager protocol.