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.
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.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
