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 <gu...@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 <meha...@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 <gu...@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 <random...@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/ > > > > > > > > -- > --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
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/