On 12/2/2021 2:21 PM, Brendan Barnwell wrote:
On 2021-12-02 01:35, Steven D'Aprano wrote:
> >4) If "no" to question 1, is there some other spelling or other
small
> >change that WOULD mean you would use it? (Some examples in the
PEP.)
>
> No. As I mentioned in the earlier thread, I don't support any
> proposal in which an argument can "have a default" but that
default is not
>a first-class Python object of some sort.
I don't understand this criticism.
Of course the default value will be a first-class Python object of some
sort.*Every* value in Python is a first-class object. There are no
machine values or unboxed values, and this proposal will not change
that.
All that this proposal changes is*when* and*how often* the default
will be evaluated, not the nature of the value.
As has happened often in these threads, it seems different people
mean different things by "default value".
What you are calling "the default value" is "a thing that is used
at call time if no value is passed for the argument". What I am
calling "the default value" is "a thing that is noted at definition
time to be used later if no value is passed for the argument".
What I'm saying is that I want that "thing" to exist. At the time
the function is defined, I want there to be a Python object which
represents the behavior to be activated at call time if the argument
is not passed. In the current proposal there is no such "thing". The
function just has behavior melded with its body that does stuff, but
there is no addressable "thing" where you can say "if you call the
function and the argument isn't passed were are going to take this
default-object-whatchamacallit and 'use' it (in some defined way) to
get the default value". This is what we already have for early-bound
defaults in the function's `__defaults__` attribute.
I also have this objection to the proposal (among other concerns).
Say I have a function with an early-bound default. I can inspect it and
I can change it. One reason to inspect it is so that I can call the
function with its default values. This is a form of wrapping the
function. I realize "just don't pass that argument when you call the
function" will be the response, but I think in good faith you'd have to
admit this is more difficult than just passing some default value to a
function call.
As far as changing the defaults, consider:
>>> def f(x=3): return x
...
>>> f()
3
>>> f.__defaults__=(42,)
>>> f()
42
The current PEP design does not provide for this functionality for
late-bound defaults.
I realize the response will be that code shouldn't need to do these
things, but I do not think we should be adding features to python that
limit what introspections and runtime modifications user code can do.
A classic example of this is PEP 362 function signature objects. I don't
think we should be adding parameter types that cannot be represented in
a Signature, although of course a Signature might need to be extended to
support new features. Signature objects were added for a reason (see the
PEP), and I don't think we should just say "well, that's not important
for this new feature". Also note that over time we've removed
restrictions on Signatures (see, for example, Argument Clinic). So I
don't think adding restrictions is the direction we want to go in.
Eric
_______________________________________________
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/A5Y2ANSD52TZMPSS4ODXXHJQKHCFTDPG/
Code of Conduct: http://python.org/psf/codeofconduct/
