[Python-ideas] PEP 505: None-aware operators

Steve Dower steve.dower at python.org
Mon Jul 23 06:38:11 EDT 2018


On 23Jul2018 1129, Antoine Pitrou wrote:
> 
> Le 23/07/2018 à 12:25, Steve Dower a écrit :
>> On 23Jul2018 1111, Antoine Pitrou wrote:
>>> On Mon, 23 Jul 2018 10:51:31 +0100
>>> Steve Dower <steve.dower at python.org> wrote:
>>>>
>>>> Which is the most important operator?
>>>> -------------------------------------
>>>>
>>>> Personally, I think '?.' is the most valuable.
>>>
>>> For me, it's the most contentious.  The fact that a single '?' added to
>>> a regular line of Python code can short-circuit execution silently is a
>>> net detriment to readability, IMHO.
>>
>> The only time it would short-circuit is when it would otherwise raise
>> AttributeError for trying to access an attribute from None, which is
>> also going to short-circuit.
> 
> But AttributeError is going to bubble up as soon as it's raised, unless
> it's explicitly handled by an except block.  Simply returning None may
> have silent undesired effects (perhaps even security flaws).

You're right that the silent/undesired effects would be bad, which is 
why I'm not proposing silent changes to existing code (such as 
None.__getattr__ always returning None).

This is a substitute for explicitly checking None before the attribute 
access, or explicitly handling AttributeError for this case (and 
unintentionally handling others as well). And "?." may be very small 
compared to the extra 3+ lines required to do exactly the same thing, 
but it is still an explicit change that can be reviewed and evaluated as 
"is None a valid but not-useful value here? or is it an indication of 
another error and should we fail immediately instead".

Cheers,
Steve

> This whole thing reminds of PHP's malicious "@" operator.

General comment to everyone (not just Antoine): these arguments have 
zero value to me. Feel free to keep making them, but I am uninterested. 
Perhaps whoever gets to decide on the PEP will be swayed by them?


More information about the Python-ideas mailing list