[Pyrex] [Cython] Proposed change to behaviour of "not None"

[Greg Ewing]

Robert Bradshaw wrote:

> I am still -1 to the idea, but keep trying to convince me :).  
> Certainly I would like things to be more friendly then they are right  
> now, but having two kinds of extension class types that are declared  
> exactly the same way, one of which can take a None and the other  
> can't, seems odd.

I think you may be misunderstanding the proposal.
This has nothing to do with types.

The "not None" clause is an option on the *argument*
of a Python function, and it controls the kind of
type checking code that is generated on entry to
the function. There are two possibilities:

1) Code is generated to check that the argument is
either of the declared type or is None.

2) Code is generated to check that the argument is
exactly of the declared type.

Currently, (1) is the default, and the "not None"
option is required to specify (2). This is dangerous,
because people often don't know about the "not None"
feature, and subsequently end up writing code that
segfaults when someone passes None to their function
from Python land.

So I'm proposing to change the default to (2), and
require a new "or None" option to specify (1). That
way, ignorance of the feature leads to code that
raises an exception when passed None instead of
segfaulting.

Since exceptions are greatly preferable to segfaults,
I believe that this change will be beneficial.

The effect on existing code will be that some functions
that legitimately need to accept None will stop
doing so and raise exceptions instead. This ought to
be discovered fairly quickly under halfway decent
testing. Appropriate warnings during the transition
period should also make it easy to find and correct
any potential problems.

-- 
Greg