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