On Apr 12, 2010, at 9:50 AM, Dag Sverre Seljebotn wrote: > Lisandro Dalcin wrote: >> On 12 April 2010 11:34, Dag Sverre Seljebotn >> <[email protected]> wrote: >> >>> Lisandro Dalcin wrote: >>> >>>> On 12 April 2010 04:10, Stefan Behnel <[email protected]> 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.
I'm -1 to changing the default as well--control flow analysis is the way to correctly handle this. We also have the noncheck directive if people are worried about this. >> Would you accept a directive to ENABLE automatic "not None"? >> > I don't feel very happy about it, no. (But it's not for me to accept > or > reject.) > > We already have cdivision which is comparable (changes semantics in > non-exceptional case in a hard-to-spot fashion), but it was introduced > because of backwards compatibility and the 20% performance penalty. > > This one seems to have the same cons, but without backwards > compatibility and performance as pro-arguments (leaving only > convenience). And "not None" is already in the syntax. "Explicit is > better than implicit" and all that. Pyrex is about writing extension modules, and (conceptually) has a much sharper line between "python-level" and "c-level" code than we want to have in Cython. (In fact, the cdivision questions really boiled down to trying to erase this line. There was also the issue of giving subtly different answers rather than crashing...) As I've proposed before, our goal should be taking any valid Python code, pass it through the Cython compiler, and have it behave the same (except for speed, introspection, and possibly a finite list of other necessary exceptions). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
