Robert Bradshaw wrote: > On Aug 20, 2008, at 5:28 PM, Greg Ewing wrote: >> I've been thinking for a while now >> about making "not None" the default, and requiring >> "or None" to specify that None is an acceptable >> parameter value. > > I use the fact that extension types can be None all over the place. > Is this exclusively for arguments?
Yes, I think that's what Greg meant. That's the only place where this makes sense: user input into functions that use the Python calling convention. This change would affect user code at the Python API level, which I find a pretty huge impact. > Perhaps that could be OK--at least > it wouldn't break existing code silently. Well, it would still break it, though. And silent or not depends on there being enough tests in place that check if the sematically changed function really accepts None as input. I'd certainly not expect 100% coverage for this in any test suite. >From my gut feeling, I would say that in most places in lxml where I allow None to be passed for an extension type, it's in optional arguments, i.e. arguments that default to None anyway. So this wouldn't break too much there. But there are definitely other places where I do the check explicitly in the code and not in the signature, as I want to check for certain other input characteristics at the same time (or correlations with other parameters). Those places might change behaviour without easily being noticed, e.g. raise a different exception or at least a different (misleading?) exception message. > What would it be called? "or None"? That would be a sensible notation IMHO, although "or None" in Python code has slightly different semantics. It would return None whenever the parameter /itself/ considers its boolean value False, which is not the same as "being None". > I think a mode that emits tests before every cdef attribute access to > verify validity could be very useful as well. Such an option would certainly be nice for testing. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
