On Apr 12, 2010, at 9:42 PM, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 12.04.2010 16:34:
>> Lisandro Dalcin wrote:
>>> On 12 April 2010 04:10, Stefan Behnel wrote:
>>>> Gregory Ewing, 12.04.2010 02:31:
>>>>
>>>>> * Preparation is being made for making 'not None' the
>>>>> default for extension type parameters to Python functions.
>>>> I agree that this has been a source of bugs in the past, so I'm not
>>>> generally opposed to this. I really dislike breaking existing
>>>> code, but I
>>>> would expect that this is only a minor source of trouble for
>>>> users. I'm
>>>> +0.3 for such a change in Cython.
>>>
>>> Big +1 from my side. About code breakages: Cython could use a
>>> compiler
>>> directive for this in order to get the old behavior.
>>
>> I guess I should repeat my big -1 for this then.
>>
>> I think Java-like behaviour is much more appropriate (i.e. raise
>> proper
>> exceptions in the code using the variable, but allow None as a
>> value).
>>
>> Let's not break the language forever just because nobody has time to
>> implement control flow analysis now.
>
> Control flow analysis can't prevent the case that a user passes None
> into a
> Python function. It can only print a warning (not even an error)
> when it
> finds out that the code accesses C level members of an explicitly
> typed
> extension type argument where the value *may* be None. In that case,
> the
> user will have to recognise the warning as important and add a "not
> None"
> to the function signature (in an expected 95% of the cases) or
> handle this
> in explicit code (in at most 5%). Given that the simple "reject
> None" case
> is so extremely common at the Python API level, it sounds like the
> right
> thing to do by default.
>
> 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
> 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. We can turn that on now with the nonecheck
directive, but that comes at a cost. With control flow analysis, one
can make nonecheck=True be the default, and the check is only
performed the first time a cdef attribute is accessed (in a given
path), which will have the advantage of behaving like Python and
handling more than arguments without the performance degradation, as
well as not segfaulting on bad input.
I think this is the ideal long term solution, and we shouldn't be
changing the default just to change it back later.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
