[Python-ideas] Re: Non-standard evaluation for Python

This use case is nicely covered by short form for keyword arguments. So in this case instead of plot(x, z), we'd have plot(=x, =z) which would be transformed into plot(**{'x': x, 'z': z}) at compile time. This could work for any expression: foo(=lamda x: x*2) -> foo(**{'lamda x: x*2': lamda x:

[Python-ideas] Re: Make tuple a context manager

13.07.19 23:25, Kyle Stanley пише: Serhiy Storchaka wrote: Are your aware of contextlib.nested()? And why it was deprecated and removed? Was contextlib.nested() removed primarily due to to the inconsistencies mentioned in https://bugs.python.org/issue5251 or was it something else? Yes, it w

[Python-ideas] Re: Make tuple a context manager

On Jul 12, 2019, at 06:27, haael wrote: > > with tuple(open(str(_n) + '.tmp', 'w') for _n in range(1000)) as f: >for n, fn in enumerate(f): >f.write(str(n)) Another thought here: There may be good examples for what you want—although I suspect every such example will be much better h

[Python-ideas] Re: Non-standard evaluation for Python

On Jul 14, 2019, at 00:33, Anders Hovmöller wrote: > > This use case is nicely covered by short form for keyword arguments. So in > this case instead of plot(x, z), we'd have plot(=x, =z) which would be > transformed into plot(**{'x': x, 'z': z}) at compile time. This does avoid the problem of

[Python-ideas] Re: Non-standard evaluation for Python

> On 14 Jul 2019, at 20:21, Andrew Barnert wrote: > >> On Jul 14, 2019, at 00:33, Anders Hovmöller wrote: >> >> This use case is nicely covered by short form for keyword arguments. So in >> this case instead of plot(x, z), we'd have plot(=x, =z) which would be >> transformed into plot(**{'x

[Python-ideas] Re: Non-standard evaluation for Python

14.07.19 07:06, Andrew Barnert via Python-ideas пише: (Re-sending, because this was originally a reply to an off-list message by Nima Hamidi) On Jul 13, 2019, at 14:12, Nima Hamidi > wrote: Sometimes it's necessary not to evaluate the expression. Two such applica

[Python-ideas] Re: Non-standard evaluation for Python

Thank you for your question! It would depend on the implementation of DataFrame.__getitem__. Note that BoundExpression is endowed with locals and globals of the callee. So, it does have access to x in your example. I think the way that data.table in R handles this is that before evaluating the

[Python-ideas] Re: Non-standard evaluation for Python

Thank you very much for your feedback! I'm convinced that backtick is a bad choice for doing this. What about something like q"x"? It resembles other python syntaxes like b"x" or f"x". ___ Python-ideas mailing list -- python-ideas@python.org To unsubscr

[Python-ideas] Re: Non-standard evaluation for Python

Andrew Barnert wrote: > (Re-sending, because this was originally a reply to an off-list message by > Nima > Hamidi) > On Jul 13, 2019, at 14:12, Nima Hamidi ham...@stanford.edu... wrote: > > > > Sometimes it's necessary not to evaluate the expression. Two such > > applications of NSE in R > > ar

[Python-ideas] Re: Non-standard evaluation for Python

On Jul 14, 2019, at 11:53, Anders Hovmöller wrote: > > >>> On 14 Jul 2019, at 20:21, Andrew Barnert wrote: >>> >> This does avoid the problem of needing new syntax, but it seems to have >> other problems. > > Well it does introduce new syntax, just one that is generally useful. Right, sorr

[Python-ideas] Re: Non-standard evaluation for Python

On Jul 14, 2019, at 13:13, Serhiy Storchaka wrote: > > > The more interesting problem is that in general case you have not simple > `price < 1`, but `price < x` where x is a variable or more complex expression. I don’t think this one is a problem. (I mean, it does demonstrate the problem I wa

[Python-ideas] Re: Non-standard evaluation for Python

On Jul 14, 2019, at 13:46, Nima Hamidi wrote: > > Andrew Barnert wrote: >> But in your proposal, wouldn’t this have to be written as dt[price < >> 1]? I think the cost of putting the expression in ticks is at least as bad >> as the >> cost of naming the dt. >> Also: dt.price < 1 is a perfectly v

[Python-ideas] Re: Non-standard evaluation for Python

Andrew Barnert wrote: > On Jul 14, 2019, at 13:46, Nima Hamidi ham...@stanford.edu... wrote: > > Andrew Barnert wrote: > > But in your proposal, wouldn’t this have to be > > written as dt[price < > > 1]? I think the cost of putting the expression in ticks is at least as bad > > as the > > cost of