Revisiting PEP 505 – None-aware operators

[oscarbenjamin]

@barry

It feels overwhelming to me to have to try to comprehend (let alone visually notice!) something like a?.b.c?.d.e. I’d have so many questions about that in a code review, like, "how do you know that b.c will always resolve or that you want an AttributeError if it doesn’t? Why are you conditionalizing c.d? Why are some attributes guaranteed but others aren’t? Did you forget a ? somewhere?

It should feel overwhelming. Considering all of this conditionality and the possibility of values being null is important and the markers are showing you what the code does which is nontrivial logic that is usually expressed much more verbosely in Python using at least an indented block.

Your suggestion was something like

x = maybe a.b.c.d.e

with the expectation that any part of the expression could fail. If I have to review or read this code this I should see it as:

x = a?.b?.c?.d?.e

There are four possible ways that something can be missing. I have to consider all four of those cases to understand how this code interacts with the state of object a. I also have to wonder if the author of the code considered those 4 possible ways. Most likely only one of them is relevant and I would much rather see which one:

x = a.b?.c.d.e

Now it is possible that b is present or missing but there are only two cases to consider. It is clear here that the author has singled out b and that is the reason that they did not just use normal attribute access for the whole expression. If I want to understand why this is there then I can go and think about why b might be missing and what that means in the context of the whole program/operation and whether or not setting x to None is reasonable in that case. I do not need to go and investigate whether c, d or e could ever be missing.

The fact that a missing attribute or an unchecked None leads to some kind of error at runtime (and in static typing) is generally a good thing because it shows you where there are bugs: you want the AttributeError if the attribute is not there and the fix is usually fixing a typo or adding the attribute or something.

I would expect maybe to be a magnet for people to write code that fails in unexpected ways like:

• You add maybe because b might be missing.
• Later on a bug appears and now c is sometimes missing but it goes unnoticed.
• Now the wrong code path is taken for many objects that do have a valid b.

This is precisely analogous to having an overly broad try/except that either catches too many exception types or has too much code in the try block. At least if you review code like

x = a?.b?.c?.d?.e

then you can ask the author to justify the question marks and remove most of them.

With maybe I would expect never ending arguments where I tell someone not to use it because it is not correct and is a bug magnet but the alternative is more verbose and they desperately want the conciseness of maybe. It is not good to create this tight contention between correctness vs conciseness/elegance/etc.