Re: [Python-ideas] 'where' statement in Python?
MRAB wrote:
Why use 'as'? Why not:
i would use as because this whole where clause acts very similarly to a context manager in that it sets a variable to a value for a small block
c = a + b with:
get_a(), get_b() as a, b
is equivilent to
with get_a(), get_b() as a, b:
c = a + b
assuming get_a() and get_b() are context manager that return the values of a and b and then delete them at the end
the thing with this though it that the get_a() and get_b() do not need to be context managers the interpreter will create one so this will be valid:
c = a**2 with:
4 as a
i.e. it creates a context manager whose __enter__ method returns 4 and whose exit method deletes a from the current namespace
strula moldan wrote:
That will not work, the parser would think like this:
c = sqrt(a*a + b*b) with: get_a(), (get_b() as a), b
sorry haven't used 'as' in a while and i forgot that you could not use it like you can everything else in compound assignments (BTW why isn't a, b as c, d allowed it makes sense especially since a, b = c, d is allowed it should be changed so it does)
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.
i think you miss the point which is understandable considering such a short example but consider if there are many many steps used to arrive at the variable. you can give it a simple, descriptive name and nobody needs to see how you got it unless they want to. or a situation where you have many many variables in the with statement and it is possible to understand from their names what they represent. i.e. sea = water() with (get_temperature(sea) as temp, get_depth(sea) as depth, get_purity(sea) as purity, get_salinity(sea) as saltiness, get_size(sea) as size #etc for a few more lines get_density(sea) as density): sea_num = temp**depth + purity - salinity * size - density # one line only is much harder to understand than simply sea_num = temp**depth + purity - salinity * size - density with: # one line only get_temperature(sea) as temp, get_depth(sea) as depth, get_purity(sea) as purity, get_salinity(sea) as saltiness, get_size(sea) as size #etc for a few more lines get_density(sea) as density the meaning of all the words is obvious (assuming you know that sea_num has to do with the sea and water) and since it is you do not really need to have all that clutter up above and can just put it below
On Tue, Jul 20, 2010 at 3:15 PM, MRAB
Alex Light wrote:
i would suggest overloading the 'with', 'as' combo
c = sqrt(a*a + b*b) with:
get_a(), get_b() as a, b
or
c = sqrt(a*a + b*b) with:
get_a() as a
get_b() as b
Why use 'as'? Why not:
c = sqrt(a*a + b*b) with:
a = get_a()
b = get_b()
which is like:
def _():
a = get_a()
b = get_b()
return sqrt(a*a + b*b)
c = _()
del _
it reads well and plus it follows since this statement acts similarly to a regular with and as statement with the behavior of the context manager being (in psudocode): set up: store original value of variable if any and set variable to new value.
tear down: set value back to original or delete from local namespace if it never had one
additionally we do not need to introduce any new keywords
any way that this is implemented though it would be quite useful
On Tue, Jul 20, 2010 at 2:35 PM, George Sakkis
> wrote: On Tue, Jul 20, 2010 at 8:29 PM, Daniel Stutzbach
> On Tue, Jul 20, 2010 at 1:16 PM, Guido van Rossum
mailto:guido@python.org> wrote: >>
>> Given the large number of Python users familiar with SQL compared
to
>> those familiar with Haskell, I think we'd do wise to pick a
different
>> keyword instead of 'where'. I can't think of one right now though.
>
> Taking a cue from mathematics, how about "given"?
>
> c = sqrt(a*a + b*b) given:
> a = retrieve_a()
> b = retrieve_b()
Or if we'd rather overload an existing keyword than add a new one,
"with" reads well too.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
participants (3)
-
Alex Light
-
Chris Rebert
-
Nick Coghlan