<div dir="ltr"><br><br>On Tuesday, July 24, 2018 at 2:39:19 AM UTC+2, Steven D'Aprano wrote:<br><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">PEP 505 has a section explaining why catching AttributeError 
<br>is undesirable. I find the reasons it gives are compelling.
<br>
<br>Can you explain why you reject the PEP's arguments against catching 
<br>AttributeError?
<br> 
<br></blockquote><div><br></div><div>Yes, and people have done it multiple time already. I will try to make it as explicit as possible, with a terminology that some may find useful...</div><div>when u have a object hierarchy linked through attributes, which -seems- the use pattern of ?. , the hierarchy is either<br></div><div>- 1) fully regular (each attribute contains the same type of objects (same type=with the same attributes), then normal . access is what you want</div><div>- 2) regular-or-None (contain same type of objects, or None). That's what ?. is for, and ?. is only for that.<br></div><div>- 3) its partially regular (does not contain the same type of objects, some objects have more attributes than other, e.g. partial objects).</div><div>- 4) its irregular (objects may be of completely different type (int, str,... and do not specailly share attributes).</div><div><br></div><div>?. is intended for 2).</div><div>2) and 3) can be dealed with swallowing AttributeError</div><div>4) can also be traversed swallowing AttributeError, but it's probably a very bad idea in almost all cases.</div><div><br></div><div>I've encountered all cases, from time to time, but none is really typical of most of my code. Which is more common? not sure, I would say 3). <br></div><div>What is sure is that 2) do not stand as hugely more common than the others, so introducing a special syntax for 2) do not  please me, so +0... <br></div><div>Now as I find ?. unpleasant to parse (personal opinion), and having grown to share the general operaror / line noise allergy mainstream in the python community, i am a firm -1 on this: too small a niche, do not bring much compared to current approach, and visual line noise.</div><div>firm -1 on ?? too, it's less polemic, less visually displeasing, but even less usefull I think: it does not gain that much compared to a more general ternary.</div><div><br></div><div>As the pymaybe/this thread cover 2) and 3), and do it without any change to python, I find it better. No change > lib change > backward compatible object change  - like dict becoming ordered, or None triggering NoneAttributeError(AttributeError) > syntax change (expecially a bunch of linenoisy operators).</div><div><br></div><div>Now I will stop for a while here, arguments have become circular, 
proponents and opponents have exposed their view, but mostly proponents have provided very few additional 
information for a while, especially about real use cases, despite a few requests. <br></div><div>We still do not know what motivated the proposal..We had to guess (JSON). <br></div><div>Even the PEP do not say, it provide a set of real world example from the standard library, which is admirable but different. And personaly, while am very thankful for providing those concrete examples, I find them unconvicing: the code before is usually fine and improved little by the new operators. Sometimes it's worse: only slightly shorter and less clear.<br></div></div>