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

> On 17 Jul 2019, at 22:18, Andrew Barnert wrote: > > On Jul 17, 2019, at 12:29, Anders Hovmöller wrote: >> On 17 Jul 2019, at 21:00, Andrew Barnert wrote: On Jul 17, 2019, at 10:45, Anders Hovmöller wrote: >> On 17 Jul 2019, at 19:08, Andrew Barnert wrote: >>

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

On Jul 17, 2019, at 12:29, Anders Hovmöller wrote: > >>> On 17 Jul 2019, at 21:00, Andrew Barnert wrote: >>> >>> On Jul 17, 2019, at 10:45, Anders Hovmöller wrote: >>> > On 17 Jul 2019, at 19:08, Andrew Barnert wrote: > > On Jul 15, 2019, at 05:25, Anders Hovmöller wrote: >

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

> On 17 Jul 2019, at 21:00, Andrew Barnert wrote: > >> On Jul 17, 2019, at 10:45, Anders Hovmöller wrote: >> On 17 Jul 2019, at 19:08, Andrew Barnert wrote: On Jul 15, 2019, at 05:25, Anders Hovmöller wrote: >> >> What is positional? > >>> I didn’t come up with the

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

On Jul 17, 2019, at 10:45, Anders Hovmöller wrote: > >>> On 17 Jul 2019, at 19:08, Andrew Barnert wrote: >>> >>> On Jul 15, 2019, at 05:25, Anders Hovmöller wrote: > > What is positional? >> I didn’t come up with the plot example, so I don’t know the reason it took >> two functions.

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

> On 17 Jul 2019, at 19:08, Andrew Barnert wrote: > >> On Jul 15, 2019, at 05:25, Anders Hovmöller wrote: >> >> > (The fact that they’re positional, but passed as if they were keyword, > accepted as if they were keyword, and then pulled out by iterating **kw > in order is also

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

On Jul 15, 2019, at 05:25, Anders Hovmöller wrote: > > (The fact that they’re positional, but passed as if they were keyword, accepted as if they were keyword, and then pulled out by iterating **kw in order is also confusing.) >>> >>> What is positional? >> >> The name-value p

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

> On 15 Jul 2019, at 10:23, Andrew Barnert wrote: > >> On Jul 15, 2019, at 00:27, Anders Hovmöller wrote: >> >> >>> On 14 Jul 2019, at 22:46, Andrew Barnert wrote: >>> >>> But this doesn’t in any way help with late eval. >> >> Ah. Now I'm with you. Yes this is different but it also seems

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

On Mon, Jul 15, 2019 at 7:17 PM Andrew Barnert via Python-ideas wrote: > > Consider the case where dt is a join of two tables d1 and d2. Today you can > write dt[d1.price * d2.taxrate < x]. With the proposed new feature, you could > presumably write dt[price * taxrate < x], and get an exception

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

On Jul 15, 2019, at 01:27, Serhiy Storchaka wrote: > > 14.07.19 23:20, Nima Hamidi пише: >> 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

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

14.07.19 23:20, Nima Hamidi пише: 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

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

On Jul 15, 2019, at 00:27, Anders Hovmöller wrote: > > >> On 14 Jul 2019, at 22:46, Andrew Barnert wrote: >> >> But this doesn’t in any way help with late eval. > > Ah. Now I'm with you. Yes this is different but it also seems strange that we > wouldn't just use a lambda or a function for t

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

> On 14 Jul 2019, at 22:46, Andrew Barnert wrote: > >>> First, the function only gets the names, not live expressions that it can >>> eval late, or in a modified environment, etc., so it only handles this >>> case, not cases like df[year>1990]. >> >> I don't understand how it's not the full

[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

[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

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 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

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

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

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

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

> 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

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

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: Non-standard evaluation for Python

Delaying evaluation in some way looks like a useful feature which was up to this point integrated to python only by introducing special syntax for each problem which appeared. Out of my mind: the "conditional if trueresult else falseresult" appeared because one can't write something like if(conditi

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

(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 > applications of NSE in R are as follows: > > 1. Data-tables have cleaner syntax. For

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

It's an interesting idea, and has come up occasionally before. It probably stems from Lisp, where it's common practice (IIRC control flow like 'if' is defined this way). I believe it's called quoting there -- I've never heard the term NSE before. (Is that term specific to R?) I'm glad you start ou

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

Thank you very much for your reply! I wasn't familiar with MacroPy. It's a good idea to implement NSE using it. I'll work on it. Sometimes it's necessary not to evaluate the expression. Two such applications of NSE in R are as follows: 1. Data-tables have cleaner syntax. For example, letting d

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

On Jul 13, 2019, at 12:16, Nima Hamidi wrote: > > > In the following, I sketch how I think this can be implemented: > Let BoundExpression be a class containing an ast.Expression as well as locals > and globals dictionaries. BoundExpression can also have an eval method that > evaluates its expr