[Python-ideas] A better (simpler) approach to PEP 505

[Grégory Lielens]

On Tuesday, July 24, 2018 at 2:39:19 AM UTC+2, Steven D'Aprano wrote:

> PEP 505 has a section explaining why catching AttributeError 
> is undesirable. I find the reasons it gives are compelling. 
>
> Can you explain why you reject the PEP's arguments against catching 
> AttributeError? 
>   
>

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...
when u have a object hierarchy linked through attributes, which -seems- the 
use pattern of ?. , the hierarchy is either
- 1) fully regular (each attribute contains the same type of objects (same 
type=with the same attributes), then normal . access is what you want
- 2) regular-or-None (contain same type of objects, or None). That's what 
?. is for, and ?. is only for that.
- 3) its partially regular (does not contain the same type of objects, some 
objects have more attributes than other, e.g. partial objects).
- 4) its irregular (objects may be of completely different type (int, 
str,... and do not specailly share attributes).

?. is intended for 2).
2) and 3) can be dealed with swallowing AttributeError
4) can also be traversed swallowing AttributeError, but it's probably a 
very bad idea in almost all cases.

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). 
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... 
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.
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.

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).

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. 
We still do not know what motivated the proposal..We had to guess (JSON). 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180724/0c528d15/attachment-0001.html>