I'm not sure this answers Chris's question about "technical and
emotional baggage," but I hope to clarify the Lisp model a bit.
2qdxy4rzwzuui...@potatochowder.com writes:
> As prior art, consider Common Lisp's lambda expressions[...].
> The human description language/wording is different; , but what Python
> spells "default value," Common Lisp spells "initform." Python is
> currently much less flexible about when and in what context default
> values are evaluated; PEP-671 attempts to close that gap, but is
> hampered by certain technical and emotional baggage.
No, they're equally flexible about when. The difference is that Lisp
*never* evaluates the initform at definition time, while Python
*always* evaluates defaults at definition time.
Lisp's approach is more consistent conceptually than Chris's
proposal.[1] That is, in Lisp the initform is conceptually always a
form to be evaluated[2], while in Chris's approach there are default
values and default expressions. In practice, Lisp marks default
values by wrapping them in a quote form[3]. Thus where Lisp always
has an object that is introspectable in the usual way, Chris's
proposal has an invisible thunk that can't be introspected that way
because it's inlined into the compiled function.
>From the naive programmer's point of view, Chris vs. Lisp just flips
the polarity of marked vs. unmarked. The difference only becomes
apparent if you want to do a sort of metaprogramming by manipulating
the default in some way. This matters in Lisp because of macros,
which can and do cut deeply into list structure of code, and revise it
there. I guess it might matter in MacroPy, but I don't see a huge
loss in Python 3.
> (OTOH, Common Lisp's lambda expressions take one more step and include
> so-called "aux variables," which aren't parameters at all, but variables
> local to the function itself. I don't have enough background or context
> to know why these are included in a lambda expression.)
It's syntactic sugar that does nothing more nor less than wrap a let
form binding the aux variables around the body of the definition.
Footnotes:
[1] But then everything in Lisp is more consistent because the List
is the One DataType to Rule Them All and in the darkness bind them.
[2] Even the default default of nil is conceptually evaluated:
(eval nil) => nil. The compiler is allowed to optimize the
evaluation away if it can determine the result, as in the case of
nil or a lambda form (both of which eval to themselves).
[3] (quote x) or 'x is a special form that does not evaluate its
argument, and returns it as-is when the quote form is evaluated.
_______________________________________________
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/NRELKXB2YGF7UT3WFCPHGNFR3LB4ZQO4/
Code of Conduct: http://python.org/psf/codeofconduct/
