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
On 01/12/2021 06:16, Chris Angelico wrote: 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