(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@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@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@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@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/