On Apr 12, 2010, at 11:28 PM, Stefan Behnel wrote:
> 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.
OK, fair enough.
>>> 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?
No, I see it as very related--the whole reason "not none" is being
promoted is to avoid segfaults. Do you still want None to be rejected
by default when we have control-flow enabled nonecheck around?
> Or would you want to drop the "not None" feature entirely once we
> can trace variable values?
We can still keep it around.
> 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.
But this is the case of *every* typed extension type variable, and
you're proposing special casing python function arguments. I see
def func(MyType x):
...
as shorthand for
def func(o):
cdef MyType x = o
...
or at least feel uneasy with them behaving differently.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
