[Python-ideas] Null coalescing operator

Fri Oct 14 13:50:27 EDT 2016

For what it's worth, I like the C# syntax with question marks.

It is probably more risky (breaks more code) to introduce a new keyword
than a new symbol as operator.

If we have to pick a symbol, it's less confusing if we pick something
another language already uses.  There is no shame in copying from other
languages.  Many of them copy ideas from Python as well ;-)

Thanks.

On 14 October 2016 at 17:10, Guido van Rossum <guido at python.org> wrote:

> I actually think the spelling is the main stumbling block. The
> intrinsic value of the behavior is clear, it's finding an acceptable
> spelling that hold back the proposal.
>
> I propose that the next phase of the process should be to pick the
> best operator for each sub-proposal. Then we can decide which of the
> sub-proposals we actually want in the language, based on a combination
> of how important the functionality is and how acceptable we find the
> spelling.
>
> --Guido
>
> On Thu, Oct 13, 2016 at 8:20 PM, Mark E. Haase <mehaase at gmail.com> wrote:
> > (Replying to multiple posts in this thread)
> >
> > Guido van Rossum:
> >>
> >> Another problem is PEP 505 -- it
> >> is full of discussion but its specification is unreadable due to the
> >> author's idea to defer the actual choice of operators and use a
> >> strange sequence of unicode characters instead.
> >
> >
> > Hi, I wrote PEP-505. I'm sorry that it's unreadable. The choice of emoji
> as
> > operators was supposed to be a blatant joke. I'd be happy to submit a new
> > version that is ASCII. Or make any other changes that would facilitate
> > making a decision on the PEP.
> >
> > As I recall, the thread concluded with Guido writing, "I'll have to think
> > about this," or something to that effect. I had hoped that the next step
> > could be a survey where we could gauge opinions on the various possible
> > spellings. I believe this was how PEP-308 was handled, and that was a
> very
> > similar proposal to this one.
> >
> > Most of the discussion on list was really centered around the fact that
> > nobody like the proposed ?? or .? spellings, and nobody could see around
> > that fact to consider whether the feature itself was intrinsically
> valuable.
> > (This is why the PEP doesn't commit to a syntax.) Also, as unfortunate
> side
> > effect of a miscommunication, about 95% of the posts on this PEP were
> > written _before_ I submitted a complete draft and so most of the
> > conversation was arguing about a straw man.
> >
> > David Mertz:
> >>
> >> The idea is that we can easily have both "regular" behavior and None
> >> coalescing just by wrapping any objects in a utility class... and
> WITHOUT
> >> adding ugly syntax.  I might have missed some corners where we would
> want
> >> behavior wrapped, but those shouldn't be that hard to add in principle.
> >
> >
> > The biggest problem with a wrapper in practice is that it has to be
> > unwrapped before it can be passed to any other code that doesn't know
> how to
> > handle it. E.g. if you want to JSON encode an object, you need to unwrap
> all
> > of the NullCoalesce objects because the json module wouldn't know what
> to do
> > with them. The process of wrapping and unwrapping makes the resulting
> code
> > more verbose than any existing syntax.
> >>
> >> How much of the time is a branch of the None check a single fallback
> value
> >> or attribute access versus how often a suite of statements within the
> >> not-None branch?
> >>
> >> I definitely check for None very often also. I'm curious what the
> >> breakdown is in code I work with.
> >
> > There's a script in the PEP-505 repo that can you help you identify code
> > that could be written with the proposed syntax. (It doesn't identify
> blocks
> > that would not be affected, so this doesn't completely answer your
> > question.)
> >
> > https://github.com/mehaase/pep-0505/blob/master/find-pep505.py
> >
> > The PEP also includes the results of running this script over the
> standard
> > library.
> >
> > On Sat, Sep 10, 2016 at 1:26 PM, Guido van Rossum <guido at python.org>
> wrote:
> >>
> >> The way I recall it, we arrived at the perfect syntax (using ?) and
> >> semantics. The issue was purely strong hesitation about whether
> >> sprinkling ? all over your code is too ugly for Python, and in the end
> >> we couldn't get agreement on *that*. Another problem is PEP 505 -- it
> >> is full of discussion but its specification is unreadable due to the
> >> author's idea to defer the actual choice of operators and use a
> >> strange sequence of unicode characters instead.
> >>
> >> If someone wants to write a new, *short* PEP that defers to PEP 505
> >> for motivation etc. and just writes up the spec for the syntax and
> >> semantics we'll have a better starting point. IMO the key syntax is
> >> simply one for accessing attributes returning None instead of raising
> >> AttributeError, so that e.g. `foo?.bar?.baz` is roughly equivalent to
> >> `foo.bar.baz if (foo is not None and foo.bar is not None) else None`,
> >> except evaluating foo and foo.bar only once.
> >>
> >> On Sat, Sep 10, 2016 at 10:14 AM, Random832 <random832 at fastmail.com>
> >> wrote:
> >> > On Sat, Sep 10, 2016, at 12:48, Stephen J. Turnbull wrote:
> >> >> I forget if Guido was very sympathetic to null-coalescing operators,
> >> >> given somebody came up with a good syntax.
> >> >
> >> > As I remember the discussion, I thought he'd more or less conceded on
> >> > the use of ? but there was disagreement on how to implement it that
> >> > never got resolved. Concerns like, you can't have a?.b return None
> >> > because then a?.b() isn't callable, unless you want to use a?.b?() for
> >> > this case, or some people wanted to have "a?" [where a is None]
> return a
> >> > magic object whose attribute/call/getitem would give no error, but
> that
> >> > would have to keep returning itself and never actually return None for
> >> > chained operators.
> >> > _______________________________________________
> >> > 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/
> >
> >
>
>
>
> --
> --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/
>

-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20161014/0028b01f/attachment-0001.html>