Reconsider "not None" versus "or None" for typed object arguments

[scoder]

We had discussions at some point about switching from the opt-out "not None" qualifier for object typed function arguments to an opt-in "or None". The rational is that people tend to forget more often than not that None is a valid argument value, and fail to guard their code against it. This also applies to memory views and buffer arguments. Rejecting None and allowing it optionally might be a safer default behaviour.

However, the current default is also the normal Python behaviour. And this feature would then also have to be available in pure Python mode somehow, where None is always a valid value. Both might count as arguments for not changing the behaviour.

[robertwb]

Yeah, this is a tough call. I do think we have to stick close to Python here. It may be worth investigating how cheap we can make guarding all unsafe access.

…

On Thu, Nov 1, 2018 at 7:51 AM Stefan Behnel ***@***.***> wrote: We had discussions at some point about switching from the opt-out "not None" qualifier for object typed function arguments to an opt-in "or None". The rational is that people tend to forget more often than not that None is a valid argument value, and fail to guard their code against it. This also applies to memory views and buffer arguments. Rejecting None and allowing it optionally might be a safer default behaviour. However, the current default is also the normal Python behaviour. And this feature would then also have to be available in pure Python mode somehow, where None is always a valid value. Both might count as arguments for not changing the behaviour. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2696>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAdqgRizu_6SqoSNrY8oc189irbuM_cRks5uqpoOgaJpZM4YF4Ld> .

[scoder]

I'm rejecting this idea for the reasons given above. It's not obvious that changing it to or None would make it better overall, and it comes with its own set of drawbacks.

[scoder]

This has now been implemented as part of #3400 / #2903 when Python type annotations are used. When types are provided in Python syntax, we apply standard Python typing semantics that require Optional[...] when None is allowed. Since such code is either Python code or newly written Cython code, this avoids a major issue with backwards incompatibility.