[Python-ideas] Null coalescing operators

[Mark E. Haase]

Andrew, thanks for putting together that hack. I will check it out.

Guido, you lost me at "hate odd punctuation ... maybe a different syntax
can be invented". Do you mean introducing a new keyword or implementing
this as a function? Or do you mean that some other punctuation might be
less odd?

I'm willing to write a PEP, even if it's only purpose is to get shot down.


On Fri, Sep 18, 2015 at 3:45 PM, Guido van Rossum <guido at python.org> wrote:

> 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)
>
> _______________________________________________
> 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/
>



-- 
Mark E. Haase
202-815-0201
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150918/b657bac3/attachment.html>