Re: PEP 505 (None-aware operators) for Python 3.11

Hi Steven!

On 21.09.22 13:17, Steven D'Aprano wrote:
> The distinction you make between user-defined and non-user-defined
> classes doesn't hold water. If you allow that (say) `int|None` **might**
> be acceptable, then why would `Integer|None` **necessarily** be lazy and
> bad just because int is written in C and built into the intepreter while
> Integer is written in Python by a user?
> 
> The laziness/badness of `SomeType|None` must depend on the semantics of
> SomeType, not the implementation language or who wrote it.
> 
> "Our API was lazy and bad because it uses None, but then it got accepted
> into Python as a builtin, so now it is no longer lazy or bad." /s

I considered a while if "user-defined types/classes" is the right 
wording, but didn't find a better alternative. The point I'm making is 
that `X|None` could especially then hide bugs if X defines attributes 
that will often be accessed in a chain. For int or float, there are only 
a few methods, which are arguably rarely used and chaining is probably 
not used at all. Plus, providing nulltypes for primitives would feel 
very awkward.

Consider

```
x: int | None = 5
# ...
if x is not None:
     y = 1 << x.bit_cont()
```

The typo with bit_cont() is hidden whenever x is None, so it might be 
missed by unit tests with limited coverage. However, using a nullable 
variant of it would probably make it look like this:

```
class Int(int):
     # ...

class NoneInt(Int):
     # ...

x = Int(5)   # With the option for NoneInt()
# ...
x_bit_count = x.bit_cont()
if x_bit_count == NoneInt:
     y = 1 << x_bit_count
```

This is certainly not pretty for something basic as an int, plus there 
will most likely be a performance hit when replacing every int by Int(), 
not to mention compatibility issues with APIs/libraries expecting plain int.

On the other hand, more complex classes like in the mentioned publisher 
API could indeed profit from such null-types, since a chain like

```
book?.publisher?.owner?.namme
```

will hide the typo with namme whenever any of book, publisher or owner 
is None, so there is much more potential here to miss it in a unit test.

This is actually the distinction that I wanted to make, not in the 
technical sense if a class is defined in the standard library or not.

>> The problem is, that I never actually thought about his suggested way.
> 
> Some people have, and found that it doesn't always simplify the API that
> much, or at all. If you end up replacing `obj is None` with `obj == NULL`
> or `obj.isnull()` then you haven't really gained much.

Certainly. But without None-aware operators, the gain in readability can 
be large, if you can just write

```
name = book.publisher.owner.name
if name is not None:   # No NoneStr here, see above
     # ...
```

versus

```
if (book is not None) and (book.publisher is not None) and ...:
     # ...
```

Just to be clear: I've been thankful for the comment and explanation of 
Steve Dower, because I've never thought about it that way and now see 
constructs in my code, where such a concept really would have simplified 
things and improved robustness. For others to profit as well, I would be 
glad to see this mentioned in the docs, so that it can be found even 
when not actually looking for it.
But I certainly don't want to say that this concept must be followed 
everywhere or that "X|None" is necessarily a bad thing. After all, I'd 
still love to see Python supporting such None-aware operators.

Best regards,
Philipp