On Apr 13, 2010, at 4:13 AM, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 13.04.2010 09:11:
>> Stefan Behnel wrote:
>>> Dag Sverre Seljebotn, 13.04.2010 08:19:
>>>> 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".
>>>
>>> Sorry, but that case is so trivial to handle implicitly that I
>>> can't see
>>> how this is supposed to be an argument against changing the default.
>>
>> The argument against changing the default is simply that there is
>> another option which is much closer to Python semantics (and IMHO
>> more
>> user friendly as the user don't have to care about declaring "not
>> None"
>> manually).
>
> Well, but that's the whole point of doing this change. To keep users
> from
> having to write "not None" manually. Requiring "or None" instead
> would a)
> immediately drop all dangerous cases where users forget to test for
> None,
> b) make it obvious in the source where None is a valid value, and
> c) allow
> the future control flow analysis to know that the argument cannot be
> None
> unless specified otherwise, so that it can drop all implicit None
> tests
> from the source. We could then even emit a warning for explicit "is
> None"
> tests in the source to make users aware that the value cannot be
> None at
> this point.
Are you saying that
def foo(X x not None):
x = None
would raise an error? (I.e. x is now some special type that can only
be declared in arguments?) I do think such a type could be useful in
general, but there's the issue of initial values...
> So I really don't see why future control flow analysis capabilities
> should
> be negatively impacted by this change, or why they would render this
> feature redundant. All this change really does is relieve users from
> having
> to write "not None" in most of their Python level functions.
Perhaps here is the difference in perspective--I don't need to write
"not None" in most of my Python level functions--None is a perfectly
valid value in a lot of the code I write. Control flow analysis
handles the dangerous part, but your point of view is that even if it
fails gracefully, allowing None is just an error waiting to happen.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
