On Sat, Oct 23, 2021 at 02:54:54PM -0700, 2qdxy4rzwzuui...@potatochowder.com
wrote:
[...]
> > The function header is a syntactic construct - the "def" line, any
> > decorators, annotations, etc.
>
> If you mean that def statements and decorators run at compile time, then
> I agree. If you mean something else, then I don't understand.
Pedantic note: def statements and decorators run at runtime, the same as
all other statements. (Including class statements.)
Broadly speaking (I may have some of the fine details wrong) there are
three stages in executing a function:
- compile-time, when the interpreter statically analyses the function
source code and compiles the body of the function, plus a set of
byte-codes (or equivalent) to assemble the function object;
- runtime, when the def *statement* is executed by running the second
lot of byte-code, and the function object is assembled -- we often
call that "function definition time"; and
- runtime, when the function object is actually called, and the first
set of byte-code, the one that represents the body of the function,
gets executed.
There is no Python code executed at compile-time, and the def statement
is not executed until runtime.
[...]
> I can't make the leap to claiming that late binding is part of defining
> the function's arguments. You say "late binding of function arguments";
> I say "the part of the function that translates the arguments into
> something useful for the algorithn the function encapsulates."
Consider what happens when you call a function now:
bisect(alist, obj)
At runtime, the interpreter has to bind arguments to parameters (and
handle any errors, such as too few or too many arguments). The bisect
function takes five parameters, but only two arguments are given. So the
interpreter currently has to look up default values for the missing
three parameters (which it gets from the function object, or possibly
the code object, I forget which).
Those values are static references to objects which were evaluated at
function definition time, so that the process of fetching the default is
nothing more than grabbing the object from the function object.
That process of the interpreter matching up arguments to parameters,
filling in missing arguments with defaults, and checking for error
conditions, is not normally considered to be part of the function
execution itself. It is part of the interpreter, not part of the
function.
Now consider what would happen if we used late binding. Everything would
be the same, *except* that instead of fetching a static reference to a
pre-existing object, the interpreter would have to fetch a reference to
some code, evaluate the code, and use *that* object as the default.
There is no reason to consider that part of the function body, it is
still performed by the interpreter.
It is only habit from 30 years of working around the lack of late-
binding defaults by putting the code inside the function body that leads
us to think that late-binding is necessarily part of the body.
In Python today, of course late-binding is part of the body, because
that's the only way we have to delay the evaluation of an expression.
But consider languages which have late-binding, I think Smalltalk and
Lisp are the two major examples. I'm not an expert on either, but I can
read StackOverflow and extrapolate a meaning to code :-)
(defun test1 (&optional (x 0))
(+ x x))
is a function that takes one argument with a default value of 0. Lisp
uses late-binding: the default value is an expression (an S-expression?)
that is evaluated when the code is called, not at compile time, but it
is not part of the body of the function (the `(+ x x)` expression.
--
Steve
_______________________________________________
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/7U5EB6VE5VA6OIXPQ4RA6B3VO6SGK2M5/
Code of Conduct: http://python.org/psf/codeofconduct/
