[Python-ideas] Null coalescing operators

[Guido van Rossum]

FWIW, I generally hate odd punctuation like this (@ notwithstanding) but
I'm not against the idea itself -- maybe a different syntax can be
invented, or maybe I could be persuaded that it's okay.

On Fri, Sep 18, 2015 at 12:28 PM, Andrew Barnert via Python-ideas <
python-ideas at python.org> wrote:

> On Sep 18, 2015, at 11:21, Trent Nelson <trent at snakebite.org> wrote:
> >
> >> On Fri, Sep 18, 2015 at 10:42:59AM -0700, Mark Haase wrote:
> >> StackOverflow has many questions
> >> <http://stackoverflow.com/search?q=%5Bpython%5D+null+coalesce> on the
> >> topic of null coalescing operators in Python, but I can't find any
> >> discussions of them on this list or in any of the PEPs. Has the
> >> addition of null coalescing operators into Python ever been discussed
> >> publicly?
>
> I believe it was raised as a side issue during other discussions
> (conditional expressions, exception-handling expressions, one of the
> pattern-matching discussions), but I personally can't remember anyone ever
> writing a serious proposal. I think Armin from PyPy also has a blog post
> mentioning the idea somewhere, as a spinoff of his arguments against PEP
> 484 (which turned into a more general "what's wrong with Python's type
> system and what could be done to fix it). One last place to look, although
> it'll be harder to search for, is every time people discuss whether things
> like dict.get are a wart on the language (because there should be a fully
> general way to do the equivalent) or a feature (because it's actually only
> useful in a handful of cases, and it's better to mark them explicitly than
> to try to generalize).
>
> But my guess is that the discussion hasn't actually been had in sufficient
> depth to avoid having it here. (Although even if I'm right, that doesn't
> mean more searching isn't worth doing--to find arguments and counter
> arguments you may have missed, draw parallels to successes and failures in
> other languages, etc.) And, even if Guido hates the idea out of hand, or
> someone comes up with a slam-dunk argument against it, this could turn into
> one of those cases where it's worth someone gathering all the info and
> shepherding the discussion just to write a PEP for Guido to reject
> explicitly.
>
> Personally, for whatever my opinion is worth (not that much), I don't have
> a good opinion on how it would work in Python without seeing lots of
> serious examples or trying it out. But I think this would be relatively
> easy to hack in at the tokenizer level with a quick&dirty import hook. I'll
> attempt it some time this weekend, in hopes that people can play with the
> feature. Also, it might be possible to do it less hackily with MacroPy (or
> it might already be part of MacroPy--often Haoyi's time machine is as good
> as Guido's).
>
> >> Python has an "or" operator that can be used to coalesce false-y
> >> values, but it does not have an operator to coalesce "None"
> >> exclusively.
> >
> > Hmmm, I use this NullObject class when I want to do stuff similar to what
> > you've described:
>
> This is a very Smalltalk-y solution, which isn't a bad thing. I think
> having a singleton instance of NullObject (like None is a singleton
> instance of NoneType) so you can use is-tests, etc. might make it better,
> but that's arguable.
>
> The biggest problem is that you have to write (or wrap) every API to
> return NullObjects instead of None, and likewise to take NullObjects. (And,
> if you use a PEP 484 checker, it won't understand that an optional int can
> hold a NullObject.)
>
> Also, there's no way for NullObject to ensure that spam(NullObject)
> returns NullObject for any function spam (or, more realistically, for any
> function except special cases, where it's hard to define what counts as a
> special case but easy to understand intuitively).
>
> And finally, there's no obvious way to make NullObject raise when you want
> it to raise. With syntax for nil coalescing, this is easy: ?. returns None
> for None, while . raises AttributeError. With separate types instead,
> you're putting the distinction at the point (possibly far away) where the
> value is produced, rather than the point where it's used.
>
> As a side note, my experience in both Smalltalk and C# is that at some
> point in a large program, I'm going to end up hackily using a distinction
> between [nil] and nil somewhere because I needed to distinguish between an
> optional optional spam that "failed" at the top level vs. one that did so
> at the bottom level. I like the fact that in Haskell or Swift I can
> actually distinguish "just nil" from "nil" when I need to but usually don't
> have to (and the code is briefer when I don't have to), but I don't know
> whether that's actually essential (the [nil]) hack almost always works, and
> isn't that hard to read if it's used sparsely, which it almost always is).
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150918/e2681a30/attachment.html>