[Pyrex] [Cython] Proposed change to behaviour of "not None"

Stefan Behnel stefan_ml at behnel.de
Thu Aug 21 13:44:46 CEST 2008


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




More information about the Pyrex mailing list