Robert Bradshaw wrote:
> 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.
>
Also there's the big advantage of allowing code like
def f(MyClass arg=None):
if arg is None:
arg = new_default_instance()
print arg.x
without any "allow None".
Dag Sverre
> 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
>
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
