On Sun, Oct 24, 2021 at 12:35 AM Marc Mueller <cdc...@gmail.com> wrote: > > > Bear in mind that these last ones are exactly equivalent to the "or" > > operator, as they'll use the default if you have any falsy value. > > variable = some_function(...) or [] > > Isn't that in itself a good argument in favor of (??) ? By missing to add 'is > None', I would have already added a subtle bug that could be quite difficult > to find. (??) could prevent that while also being more readable. >
Perhaps, but your alternate versions were identically buggy, which means that - in all probability - the bug wouldn't have been relevant. For instance, if you're asking for a file-like object, and will use stdout if no argument is passed, it's absolutely fine to use None as a default and "or" to replace it with sys.stdout, because only a pathological example will actually cause problems. And that's fine. There are myriad use-cases for a None-coalescing operator that would work just fine without one; if Python had such an operator, sure, it could be used, but they're not strong arguments for adding one. > > I'm actually more interested in a better idiom for non-constant > > function default arguments, since that's the place where this kind of > > thing often comes up. A nice ??= operator might help if your default > > is None, but if you then change the default to be object(), you can't > > use ??= any more. [...] > > True, but from my experience 'None' is just by far the most common default. > Why not improve how we handle it? > There are three situations to consider here: 1) Situations where there's no falsy value that would make sense 2) Situations where None is used and there are other falsy values that would make sense 3) Situations where any object makes sense The only ones where None-coalescing is truly significant are the second group. In the first group, "or" and "??" would behave identically, so why bother introducing a new operator? And in the third group, the default can't be None, so it has to be an artificially-invented object. All three would be improved by a late-binding feature, but only a strict subset of them would benefit from directly replacing None with something else. Like several others here, I am much more interested in the operators that do "if None, give back None, otherwise fetch an attribute/item". If we end up getting None-coalescing for free along with that, so be it, but I'm not really pushing for that part. Proper argument late-binding is an entirely orthogonal proposal, and would have many benefits that aren't part of PEP 505 or related proposals, but would do most of what we want from the ?? operator. PEP 505 has some oddities that are hard to explain, though - and I mean that not in the sense that the PEP itself is hard to read, but that I would have to go to some effort to explain what my code does (picture a mentor/student relationship here). If I offer a line of code saying <<x = spam()?.ham.eggs or 5>>, what happens if spam returns None? Unpacking it step by step reveals a bit more complexity than it first seems to have. Python tries to minimize such situations, doing them only when there is a very clear benefit (for instance, "3 < x < 8" is very different from "(3 < x) < 8", but that's because it is immensely valuable), and I do have misgivings about that part of it. Otherwise, though, I am in favour of this and would make good use of it. (And would do so regardless of the ultimate decision on the chaining.) ChrisA _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/33M2GBBKPMYRTINEGV5ORG73AXPE643L/ Code of Conduct: http://python.org/psf/codeofconduct/
