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@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
(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
On Thu, Oct 13, 2016 at 8:20 PM, Mark E. Haase <mehaase@gmail.com> wrote: 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/
-- --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/
-- Gustavo J. A. M. Carneiro Gambit Research "The universe is always one step beyond logic." -- Frank Herbert