<div dir="ltr">The problem here is not whether it's explicit. It's about Readability and conciseness. Using symbols in place of words almost always harms readability in favor of conciseness.<br><br>value = <a href="http://person.name">person.name</a> if <a href="http://person.name">person.name</a> else person<br><br>almost reads like english (aside from being a weird and totally uncommon use case)<br><br>value = person?.name<br><br>Is a huge step towards the concise illegible soup of symbols that Perl is famous for. It's a huge No from me.<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 25, 2018 at 11:12 AM, Nicholas Chammas <span dir="ltr"><<a href="mailto:nicholas.chammas@gmail.com" target="_blank">nicholas.chammas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Mon, Jul 23, 2018 at 6:05 PM Giampaolo Rodola' <<a href="mailto:g.rodola@gmail.com" target="_blank">g.rodola@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This:<br>
<br>
    v = a?.b<br>
<br>
...*implicitly* checks if value is not None [and continues execution]. This:<br>
<br>
    v = a<br>
    if a.b is not None:<br>
        v = a.b<br>
<br>
...*explicitly* checks if value is not None and continues execution.<br></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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.</div><div><br></div><div>This reminds me of something I read about once called <a href="https://thefeedbackloop.xyz/stroustrups-rule-and-layering-over-time/" target="_blank">Stroustrup's Rule</a> [1]:</div><div><br></div><div>> For new features, people insist on LOUD explicit syntax.</div><div>> For established features, people want terse notation.</div><div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>    a = 3 + 4.5</div><div><br></div><div>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.</div><div><br></div><div>[1] Bjarne Stroustrup makes the observation in <a href="https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Keynote" target="_blank">this talk</a> at 23:00.<br></div></div></div>
<br>______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
<br></blockquote></div><br></div>