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
expression, __getitem__ simply adds columns to locals and then evaluates the
expression. In your example, x already exists in locals, but the price doesn't.
So, __getitem__ adds it to locals and so everything's there to evaluate the
expression correctly. I think this feature is called "non-standard evaluation"
because it lets programmers evaluate expressions in a context other than the
standard context.
On 7/14/19, 4:15 PM, "Serhiy Storchaka" <storch...@gmail.com> wrote:
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
> <ham...@stanford.edu
> <mailto:ham...@stanford.edu>> 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 example, letting dt be a
>> data-table with a column called price, one can retrieve items cheaper
>> than $1 using the following: dt [price < 1]. Pandas syntax requires
>> something like dt[dt.price < 1]. This is currently inevitable as the
>> expression is evaluated *before* __getitem__ is invoked. Using NSE,
>> dt.__getitem__ can, first, add its columns to locals() dictionary and
>> then evaluate the expression in the new context.
>>
>
> This one looks good. I can also imagine it being useful for SQLAlchemy,
> appscript, etc. just as it is for Pandas.
>
> 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 valid expression, with a useful value.
> You can store it in a temporary variable to avoid repeating it, or stash
> it for later, or print it out to see what’s happening. But price < 1 on
> its own is a NameError, and I’m not sure what `price < 1` is worth on
> its own. Would this invite code that’s hard to refactor and even harder
> to debug?
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. price should be evaluated at the callee context while x
should be evaluated at the caller context. And how Python can know what
is what?
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/FEWKJSEP6AKFXDUPMYHHHY5EKOSJYYTV/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/LXT3NVLQPHBA37GMRU6HV5O62RTXCWDK/
Code of Conduct: http://python.org/psf/codeofconduct/
