Steven D'Aprano ""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." 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. On Wednesday, December 1, 2021 at 9:39:12 PM UTC-6 Steven D'Aprano wrote: > 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 > _______________________________________________ > Python-ideas mailing list -- python...@python.org > To unsubscribe send an email to python-id...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python...@python.org/message/G3V47ST6INLI7Y3C5RZSWVXFLNUTELQT/ > > <https://mail.python.org/archives/list/python-ideas@python.org/message/G3V47ST6INLI7Y3C5RZSWVXFLNUTELQT/> > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/5ZUI2HBXUPXUXSI66YKUFRFRA74DJXOA/ Code of Conduct: http://python.org/psf/codeofconduct/
