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 > > are as follows: > > > > > > 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? In this particular example, the payoff is negligible. But look at the following example: ``` tips[(tips['size'] >= 5) | (tips['total_bill'] > 45)] ``` This could be simplified to: ``` tips[(size >= 5) | (total_bill > 45)] ```
> > Pipe-lining in R is also much cleaner. Dplyr provided an operator %>% which > > passes > > the return value of its LHS as the first argument of its RHS. In other > > words, f() %>% > > g() is equivalent to g(f()). This is pretty useful for long pipelines. The > > way that it > > works is that the operator %>% changes AST and then evaluates the modified > > expression. > > In this example, evaluating g() is undesirable. > > > > This doesn’t seem necessary in a language with first-class functions. Why > > can’t > you just write the pipeline as something f %>% g, much as you would in, say, > Haskell, > which would just define a function (presumably equivalent to either lambda: > g(f()) or > lambda a, **kw: g(f(a, **kw))) that represents the pipeline that you then just > call normally? I don’t see the benefit in being able to write g() instead of > g here, and > in fact it seems actively misleading, because it implies calling g on no > arguments instead > of one. > Also, given that Python doesn’t have such an operator, or a way to define > custom > operators, and that proposals for even simpler operators on functions like @ > for compose > have been rejected every time they’ve been suggested, I wouldn’t expect much > traction from > this example. Is there something similar that could plausibly be done in > Python, and feel > Pythonic? Please look at the "partials" example by Xavier. I think it illustrates how this is different than function composition. _______________________________________________ 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/MQ27JRXHCWGN2QIRIQ44SNJ64CVHPIXX/ Code of Conduct: http://python.org/psf/codeofconduct/
