On 01/12/2021 06:16, Chris Angelico wrote:
I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/
with some additional information about the reference implementation,
and some clarifications elsewhere.
*PEP 671: Syntax for late-bound function argument defaults*
Questions, for you all:
1) If this feature existed in Python 3.11 exactly as described, would
you use it?
Yes, when appropriate.
2) Independently: Is the syntactic distinction between "=" and "=>" a
cognitive burden?
(It's absolutely valid to say "yes" and "yes", and feel free to say
which of those pulls is the stronger one.)
Yes. Any way PEP 671 is implemented adds to the Python learning curve
and the cognitive burden, by definition. I don't see how it is
logically possible to answer "No" to this question.
But IMHO it is well worth it.
Providing only one of early-bound and late-bound defaults (and arguably
the less useful one) is a deficiency in Python. Providing both would be
useful.
New features are added to the language because they are thought to be
useful. That means that people have to learn about them (even if they
don't write them themselves). That's life.
3) If "yes" to question 1, would you use it for any/all of (a) mutable
defaults, (b) referencing things that might have changed, (c)
referencing other arguments, (d) something else?
I can imagine using it for (a), (b) and (c). Nothing else springs to
mind at the moment.
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.)
I answered "yes" to question 1, but I'm not letting that stop me from
reiterating that I think the `=>' arrow is the wrong way round.😁 Hence
my preference for `:=` or `=:`.
5) Do you know how to compile CPython from source, and would you be
willing to try this out? Please? :)
It's lazy of me, but like others I doubt that I'll find the time. Sorry.
I'd love to hear, also, from anyone's friends/family who know a bit of
Python but haven't been involved in this discussion. If late-bound
defaults "just make sense" to people, that would be highly
informative.
Any and all comments welcomed. I mean, this is python-ideas after
all... bikeshedding is what we do best!
The reference implementation currently has some test failures, which
I'm looking into. I'm probably going to make this my personal default
Python interpreter for a while, to see how things go.
ChrisA
I agree with 3 things that Abe Dillon said in 3 separate posts:
(1) What I really don't like is @param=[] because it puts the emphasis
on the parameter name rather than the act of binding. Not only does it
make it look like @param is a special kind of variable, it also mimics
the *args and **kwargs syntax which makes them seem related.
(2) Yes, we know *why* the hack works. We're all familiar with it. That
doesn't mean it's not a hack.
The bottom line is:
you *don't actually* want the parameter to default to the value of a
sentinel.
you *have* to use that hack because you can't express what you want the
default to actually be.
You're doing something misleading to work around a shortcoming of the
language.
That's a hack.
You have to write something that you don't actually intend.
(3) 2% of functions is a lot of functions.
Best wishes
Rob Cliffe
_______________________________________________
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/2DKS7HYD5FWDKK4UT3SU3J7BRU7CSNMJ/
Code of Conduct: http://python.org/psf/codeofconduct/
