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(conditional,trueresult,falseresult) like in lisp
because of lack of delayed execution
the f"{x=}" somehow appears because one can't write something like debug(x)
without losing the name of the x variable.
A lot of uses of lambda is as an inline parameter of a function, which
might be replaced by the function taking a delayed expression as a
parameter.
lambda itself, might be think as a function and don't need special syntax
if delayed evaluation would exists.
If delayed execution some existing code might be better
namedtuple('Point',['x','y']) could be rewritten as namedtuple(Point,x,y)
partial(f,1,2) might be harder to understand than partial(f(1,2))
I already played with ast and as Guido says there is no backward
compatibility guarantee. From my memory, the code I wrote worked
only for only one minor version of python. Maybe some representation of the
code which is more independent of the needs of CPython execution model
would be nice and stable would be nice. Something isomorph to hy syntax,
that is 3 + 2 corespond to (+ 3 2) would be very nice to work with and
don't need to know the particular type of 3, 2, + in cpython internals
Macropy way to make such magic appear is to do a first import an import
hook and then import a module which is the place where you could use
delayed execution. As such I feel like only a thing you can play with, not
a thing you can ship as a library usable without special instruction.
the following would be very nice if it would plot the function
x,y->3*x+2*y on the range specified
from plotting import plot3d
plot3d(3*x+2*y,x=[0:2],y=[0,2])
I might be wrong, but the parser don't necessarily need to know which
function need delayed evaluation,
The ast of the arguments need to be accessible at function call, but it is
just a problem of save it until the execution of the function.
The fact that an argument must be evaluated just be known at the point
where the argument is supposed to be evaluated, so at execution time.
So at execution time, the source code plot(3*x) could be executed in
something similar to:
if plot.is_delayed_evaluation:
plot(("3*x",{"x":x}))
else:
plot(3*x)
A big difference between lisp macro and this proposition (as well as
initial proposition as far as can say) is that macro in lisp generate
source code at compilation while this proposition manipulate code at
execution time (If I am correct, for equivalent code,
the source code manipulation can be made only once by memoizing the delayed
evaluation code)
Xavier Combelle
Le dim. 14 juil. 2019 à 02:53, Guido van Rossum <gu...@python.org> a écrit :
> 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 out by proposing dedicated syntax -- automatically
> inferring that a particular function takes (some or all) auto-quoted
> arguments would be hard because it's the parser that would need to know,
> but the parser doesn't have access to imported function definitions. A
> dedicated syntax doesn't have this problem (though it might have other
> problems).
>
> A few problems include:
>
> - The `x` syntax is pretty ugly -- in Python 2 this was a shorthand for
> repr(x), and we removed it in Python 3 because backticks are hard to read
> (it looks like about two pixels on my screen). Also, these days `x` is
> pretty commonly used as indicator for "code" (e.g. markdown). (OTOH I don't
> have a better suggestion.)
>
> - The ast module is exempt from the usual backwards compatibility
> guarantees across minor versions -- if we need to change the AST structure
> to accommodate a new type of expression or a new feature of the compiler,
> we will do his without worrying too much about backwards compatibility. (As
> an example, in Python 3.8 the AST uses Constant for all literal node types
> (numbers and strings), whereas in previous versions there are separate Num
> and Str node types.)
>
> - If you want to evaluate a quoted expression, there are a few different
> choices depending on the use case: you might want to evaluate it in exactly
> the environment where it was first written (i.e. the caller's environment,
> including nonlocals), or you might want to evaluate it in a context
> provided by the function that's evaluating it. I *think* you are accounting
> for this, but I wanted to make sure it was on your radar.
>
> - We need a function that, given an expression, returns a reasonable
> string. We have such a function, thanks to PEP 563, although it's not
> exposed (it's written in C and used only internally to construct the
> strings that go into the __annotations__ dict). It also doesn't preserve
> whitespace exactly. Now, in order to evaluate the expression we don't need
> the whitespace, but if you want to get the string and use that as an axis
> label it could become somewhat ugly.
>
> With all that in mind, and without any promises, I do think it would be
> cool if you could code up a prototype and see how it feels. Good luck!
>
> --Guido
>
> On Sat, Jul 13, 2019 at 12:36 PM Nima Hamidi <ham...@stanford.edu> wrote:
>
>> 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. However,
>> sometimes it is useful to have access to the expressions as well. For
>> example, let plot(x, y, ...) be a function that draws the scatter plot of y
>> against x and adds labels for the x- and y-axes. Currently, there is no way
>> to distinguish plot(x, *z*, ...) from plot(x, *y*, ...) from within the
>> function. As such, one needs to pass the names of the variables to the plot
>> function to be used as the axes' labels. Using NSE, though, the function
>> can look at the expressions in the method call and use those as the default
>> value for labels. In R, this idea is used widely to make the syntax simpler.
>>
>>
>> In the following, I sketch how I think this can be implemented:
>>
>>
>> 1. 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 expression using its locals and globals
>> dictionaries.
>> 2. Let `x` be the short form for BoundExpression("x", locals(),
>> globals()). Then, the plot function can be implemented in a way that
>> plot(`x`, `y`) draws scatter plot of x and y *and also,* labels the
>> axes correctly. No need to provide labels explicitly anymore.
>> 3. A more challenging idea is to let developers decide whether their
>> functions need NSE or not. For example, when a function is defined as def
>> f(`x`), for any method call like f(x), the first argument should be
>> wrapped
>> with a BoundExpression instance.
>>
>> I would appreciate any feedback on these ideas.
>>
>> Best,
>> Nima
>>
>>
>> _______________________________________________
>> 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/QE5OTQSEQHBBWWAQVIA66YUKGK5M6QDL/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him/his **(why is my pronoun here?)*
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
> _______________________________________________
> 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/FV3IUH56CFVMODNPNACPH3EQNGUUFKS6/
> 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/2H35FGLP7OAO4Q2OHFF44ZNX4VBQWZE3/
Code of Conduct: http://python.org/psf/codeofconduct/
