On 2021-12-08 20:36, Chris Angelico wrote:
Remember, though: The comparison should be to a function that looks like this:
def f(a=[], b=_SENTINEL1, c=_SENTINEL2, d=_SENTINEL3):
if b is _SENTINEL1: b = {}
if c is _SENTINEL2: c = some_function(a, b)
if d is _SENTINEL3: d = other_function(a, b, c)
If you find the long-hand form more readable, use the long-hand form!
It's not going away. But the introspectability is no better or worse
for these two. The late-bound defaults "{}", "some_function(a, b)",
and "other_function(a, b, c)" do not exist as objects here. Using PEP
671's syntax, they would at least exist as string constants, allowing
you to visually see what would happen (and, for instance, see that in
help() and inspect.signature).
I don't want to get bogged down in terminology but I am becoming
increasingly frustrated by you using the term "default" both for things
that are values and things that are not, as if there is no difference
between them. There are no late-bound defaults here, in the sense that
I mean, which as I said before has to do with default VALUES. There is
just code in the function body that does stuff. I am fine with code in
a function body doing stuff, but that is the purview of the function and
not the argument. An individual ARGUMENT having a default VALUE is not
the same as the FUNCTION defining BEHAVIOR to deal with a missing value
for an argument.
Your discussion of this point (as I interpret it, at least) continues
to take it for granted that it is perfectly fine to move stuff between
the function signature and the function body and those are somehow the
same thing. They are not. Currently in Python there is nothing that
can be used as a default argument this way:
def f(a=<some expression here>):
. . .that cannot also be done this way:
obj = <some expression here>
def f(a=obj):
The reason I want the function defaults to "exist as objects" is to
maintain this consistency. There is no need for random code in the
function body to be accessible from outside, because, well, it's in the
function body! It's not in the signature! If you want to change that,
okay, but I feel in the PEP and your discussion of it you are not fully
acknowledging that this is actually how functions work in Python now,
and thus the PEP would break some existing assumptions and bring about a
nontrivial change in how code can be refactored. (This again may be why
there is disagreement about "how confusing" the proposed change would
be. Part of what I mean by "confusing" is that it requires changing
assumptions like the one I mentioned.)
Is there benefit in replacing just one simple case with something that
would be more readable, more program-comprehensible, etc, etc, even if
the others stay as they are?
There might be, but that's not what this PEP is, because it is not
restricted to simple cases. And even if there were such benefit, it's
not at all clear to me that it would justify the increase in the
complexity of the language. Your example above, as awkward as it is,
doesn't require the reader to know anything about Python that hasn't
changed in 10+ years. In that sense it is more readable than a new
alternative which requires the reader to learn the meaning of new syntax.
I'll also point out that you misread my original example, which was:
def f(a=[], b@={}, c=some_function(a, b), d@=other_function(a, b, c)):
Note that c is early-bound here, whereas in your example you have
changed it to "late-bound" (aka "behavior inside the function"). I
realize this was probably just a thinko, but perhaps it also gently
illustrates my point that peril lies in allowing early and late-bound
defaults to mix within the same signature. It's not always trivial to
remember which arguments are which. :-)
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
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/YMPBEP5JPPDPGAKTU4MWFL6YHQLOLSII/
Code of Conduct: http://python.org/psf/codeofconduct/
