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?
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
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
Hello all,
I would like to briefly share my thoughts on non-standard evaluation (NSE),
why this is useful, and how, potentially, it can be added to Python. In
most languages, functions have access only to the *value* of their
arguments, and not to the expressions that yielded those values.
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
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
(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