On Wed, Dec 01, 2021 at 05:16:34PM +1100, Chris Angelico wrote:
1) If this feature existed in Python 3.11 exactly as described, would you use it?
Yes I would, but probably not as often as counting cases of the "if param is None: ..." idiom might lead you to expect. The problem is, as Neil also pointed out, that it becomes tricky to explicitly ask for the default behaviour except by leaving the argument out altogether. Not impossible, as Chris mentions elsewhere, you can mess about with `*args` or `**kwargs`, but it is decidedly less convenient, more verbose, and likely to have a performance hit. So if I were messing about in the interactive interpreter, I would totally use this for the convenience: def func(L=>[]): ... but if I were writing a library, I reckon that probably at least half the time I'll stick to the old idiom so I can document the parameter: "If param is missing **or None**, the default if blah..." I reject Chris' characterisation of this as a hack. There are function parameters where None will *never* in any conceivable circumstances become a valid argument value, and it is safe to use it as a sentinel. For example, I have a function that takes a `collation=None` parameter. The collation is a sequence of characters, usually a string. Using None to indicate "use the default collation" will never conflict with some possible future use of "use None as the actual collation" because None is not a sequence of characters. In this specific case, my function's current signature is: def itoa(n, base, collation=None, plus='', minus='-', width=0, ): I could re-write it as: def itoa(n, base, collation=>_default_collation(base), plus='', minus='-', width=0, ): but that would lose the ability to explicitly say "use the default collation" by passing None. So I think that, on balance, I would likely stick to the existing idiom for this function. On the other hand, if None were a valid value, so the signature used a private and undocumented sentinel: collation=_MISSING (and I've used that many times in other functions) then I would be likely to swap to this feature and drop the private sentinel.
2) Independently: Is the syntactic distinction between "=" and "=>" a cognitive burden?
I think you know my opinion on the `=>` syntax :-) I shall not belabour it further here. I reserve the right to belabour it later on :-)
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?
Any of the above.
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.)
There's lots of Python features that I use even though I don't like the spelling. Not a day goes by that I don't wish we spelled the base class of the object hierarchy "Object", so it were easier to distinguish between Object the base class and object as a generic term for any object. If the Steering Council loves your `=>` syntax then I would disagree with their decision but still use it. -- Steve