On Tue, 11 Aug 2009, Dag Sverre Seljebotn wrote: > Lisandro Dalcin wrote: >> On Mon, Aug 10, 2009 at 9:45 PM, Greg Ewing<[email protected]> >> wrote: >>> Christopher Barker wrote: >>> >>>> I wonder why anyone would want to check on access -- this is different >>>> than bounds checking -- either the code can handle a None, or it can't. >>> To catch bugs. You're right that correct code shouldn't >>> need it (unless you catch the exception and do something >>> else, but I wouldn't recommend that -- testing for None >>> explicitly beforehand will be much more efficient). >>> >> >> I'm 100% on Greg's side... It's so easy to forget the "... not None" bit ... > > This discussion (i.e. should "not None" be the default) was done to > death earlier in here -- I strongly recommend creating a CEP for this > from the earlier discussion before any more emails are spent on this.
+1 > The sumup of the majority view was: > - With decent control flow analysis nonecheck can be made the default, > which is a better solution (as it is closer to Python) > - Since there's a better AND backwards-compatible way available in the > future, let's not break backwards compatability in the meantime (which > changing the default to "not None" would do). Two other key points were, for whoever wants to write up the CEP: - If we were to change the default to not None, there'd be no safe way of ever going back. - This handles function arguments. Extension type fields, local variables, and global variables still have the same issue that a coder needs to be aware of (for the moment). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
