[Python-ideas] Null coalescing operator

Fri Oct 14 12:10:34 EDT 2016

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)