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

[Robert Bradshaw]

On Sat, 23 Aug 2008, Greg Ewing wrote:

> 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.

No, I do I completely understand your proposal. I'm just thinking about it 
from a different perspective. To me the idea that exactly one of

def foo(ExtType x):
     ...

cdef foo(ExtType x):
     ...

can accept None, and the other throws an error, is counterintuitive. I do 
see a difference (def functions are exposed to the "outside world") but I 
think people are just as likely to shoot themselves in the foot with the 
second option as well. And people will still have to be careful with

cdef ExtType x = foo()
x.cdef_attribute

etc.

Dissalowing None in extension typed variables is not acceptable, but 
having an unmarked exception for just one case is even worse I think. I 
would certainly agree to support the "or None" keyword, and an option to 
turn this feature on, and maybe enough people will want it to justify 
making it on by default eventually.

> 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.

I agree that exceptions are preferable to segfaults. I think the right way 
to go about this is to check on c attribute access, which is a lot more 
common but can mostly (I assume) be optimized away. I would have to see 
what the performance impact is though...

- Robert