Sorry. From my tablet. "Bug magnets" (it really, really wants to autocorrect that) And yes, the problem is that the equivalent is actually: v = a if v is not None: v=a.b The semantics are simply not the ones that are intuitive to most people reading 'v = a?.b' On Wed, Jul 25, 2018, 7:01 PM Abe Dillon <abedillon@gmail.com> wrote:
The fact that a while bunch have people have commented on this subthread
while not recognizing that the semantics of the '?.' and the if blocks are entirely different suggests the operators are but magnets.
Can you explain? What do you mean by "the operators are but magnets"?
The "None coalescing" operator seems so similar to the short circuit behavior of "or" that it has pretty much no merit. It's compared to ternary statements in the last section of the PEP (which is suspiciously lacking the "or" pattern).
I would agree that Python could use some more support for EAFP <https://en.wikipedia.org/wiki/EAFP> style coding. An express-ionized version of try/catch might help there, but I'm pretty sure the search for an elegant solution to that has been relatively fruitless. The attribute access and indexing are just unreadable in my view. Maybe if the question mark came at the end of the expression it would be more readable and just mean, "if the preceding expression raises an attribute exception on a none-type object, ignore it and evaluate to None otherwise return the result of the evaluation" Then just use parentheses to capture the scope:
initial = (person.name[0])? # handles if person is None or person.name is None
but that still seems like a good way to end up with very ugly code. Haskel's Maybe seems like a much better and more readable approach.
On Wed, Jul 25, 2018 at 5:36 PM, David Mertz <mertz@gnosis.cx> wrote:
The fact that a while bunch have people have commented on this subthread while not recognizing that the semantics of the '?.' and the if blocks are entirely different suggests the operators are but magnets.
On Wed, Jul 25, 2018, 5:17 PM Nicholas Chammas < nicholas.chammas@gmail.com> wrote:
On Mon, Jul 23, 2018 at 6:05 PM Giampaolo Rodola' <g.rodola@gmail.com> wrote:
This:
v = a?.b
...*implicitly* checks if value is not None [and continues execution]. This:
v = a if a.b is not None: v = a.b
...*explicitly* checks if value is not None and continues execution.
I think both of those are equally explicit. It's just that one notation is more concise than the other. Explicitness and conciseness are related but different things.
When something is "explicit", as I understand it, that means it does what it says on the cover. There is no unstated behavior. The plain meaning of `v = a?.b` is that it expands to the longer form (`v = a; if a.b ...`), and it is just as explicit.
This reminds me of something I read about once called Stroustrup's Rule <https://thefeedbackloop.xyz/stroustrups-rule-and-layering-over-time/> [1]:
For new features, people insist on LOUD explicit syntax. For established features, people want terse notation.
I think the "explicit vs. implicit" part of this discussion is probably better expressed as a discussion about "loud vs. terse" syntax. None of the operators in PEP 505 have implicit behavior, to the best of my understanding. It's just that the operators are new and have terse spellings.
As a point of comparison, I think a good example of implicit behavior is type coercion. When you ask Python to add an int to a float
a = 3 + 4.5
all that you've explicitly asked for is the addition. However, Python implicitly converts the 3 from an int to a float as part of the operation. The type conversion isn't anywhere "on the cover" of the + operator. It's implicit behavior.
[1] Bjarne Stroustrup makes the observation in this talk <https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote> at 23:00. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/