Robert Bradshaw, 13.04.2010 07:10:
> On Apr 12, 2010, at 9:42 PM, Stefan Behnel wrote:
>> Note that we are only dealing with Python functions here, and only
>> with the
>> case that the input argument is explicitly typed, i.e like this:
>>
>> def func(MyExtType value):
>>
>> So there already is a rather large performance impact in calling this
>> function, and there already is an explicit annotation saying that
>> the value
>> is an extension type. It won't even hurt cpdef functions, where the
>> type check would happen inside of the Python wrapper.
>
> So you'd have cases where
>
> (<object>x).func(None) # runtime error
> (<MyClass>x).func(None) # segfault
The cdef calling convention dictates that type checks and coercions happen
outside of the function body. So, when you have this:
cpdef func(MyType x not None):
it's the *calling* code that has to do the None check in addition to its
type check, not the cdef function implementation. If that doesn't happen
(didn't check, but I assume it doesn't), it's a bug in the current
implementation. This is certainly something where control flow analysis can
help, but as long as that doesn't work reliably, a None check before the
call is required.
>> I accept the argument that function parameters are not the only
>> dangerous
>> place here and that values received from a function call or global
>> values
>> are best checked as well, so control flow analysis would still be
>> able to
>> print helpful warnings in other places. But the case of function
>> arguments
>> is so important that it's worth giving it distinct semantics.
>
> You are missing the point of control flow analysis here--it's not to
> warn the user when code might be None, but to raise (runtime)
> exceptions when it is.
Isn't that orthogonal to the default behaviour of typed arguments? Or would
you want to drop the "not None" feature entirely once we can trace variable
values? I think it's still a feature then, but I agree with Greg that it
works the wrong way around.
The way it currently works is that you get a type error for *every*
explicitly typed input value that cannot be converted to the target type,
*except* for the single case of passing None into an explicitly typed
extension type argument. So this is the only case that is not safe, and a
very common case where things can segfault because it's easy to forget
about. It just doesn't behave the way it looks in the code. The proposed
change is about fixing exactly this pitfall.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
