On Sat, Oct 30, 2021 at 06:54:51PM -0700, Brendan Barnwell wrote:
> I mean, here's another way to come at this. Suppose we have this
> under the proposal (using some random syntax picked at random):
>
> def foo(a=1, b="two", c@=len(b), d@=a+c):
>
> You keep saying that c and d "are argument default" just like a and
> b. So can you tell me what the argument default for each of those
> arguments?
Sure.
If you fail to provide an argument for c, the value that is bound to c
by default (i.e. the default argument) is len(b), whatever that happens
to be. If you fail to provide a value for d, the value that is bound to
d by default is a+c.
There is nothing in the concept of "default argument" that requires it
to be known at function-definition time, or compile time, or when the
function is typed into the editor.
Do you have a problem understanding me if I say that strftime defaults
to the current time? Surely you don't imagine that I mean that it
defaults to 15:34:03, which was the time a few seconds ago when I wrote
the words "current time".
And you probably will understand me if I say that on POSIX systems such
as Linux, the default permissions on newly created files is (indirectly)
set by the umask.
> Currently, every argument default is a first-class value.
And will remain so. This proposal does not add second-class values to
the language.
By the time the body of the function is entered, the late-bound
parameters will have had their defaults evaluated, and the result bound
to the parameter.
Inside the function object itself, there will be some kind of opaque
blob (possibly a function?) that holds the default's expression for
later evaluation. That blob itself will be a first class object, like
every other object in Python, even if its internal structure is
partially or fully opaque.
> As I
> understand it, your proposal breaks that assumption, and now argument
> defaults can be some kind of "construct" that is not a first class
> value, not any kind of object, just some sort of internal entity that no
> one can see or manipulate in any way, it just gets automatically
> evaluated later.
Kind of like functions themselves :-)
>>> (lambda x, y: 2*x + 3**y).__code__.co_code
b'd\x01|\x00\x14\x00d\x02|\x01\x13\x00\x17\x00S\x00'
The internal structure of that co_code object is a mystery, it is not
part of the Python language, only of the implementation, but it remains
a first-class value.
(My *guess* is that this may be the raw byte-code of the function body.)
One difference will be, regardless of how the expression for the
late-bound default is stored, there will be at the very least an API to
extract a human-readable string representing the 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/ADAOKEN7CUQQUYPY32W5Q4IQMLVYSH3V/
Code of Conduct: http://python.org/psf/codeofconduct/
