On Dec 8, 2009, at 4:29 AM, Stefan Behnel wrote: >> This may have performance ramifications...though probably small. >> Also, >> we can't make any guarantees (without extra work) about extern >> functions that are declared to return bint (which are not as uncommon >> as one would think...) > > At least for the Python .pxd files that we ship, I've taken care to > use > bint only where it's really just 0/1, although additional -1 values > can be > used as exception values, for example.
Some libraries on specify that they return a non-zero value on success/ error, yet the bint type still makes sense. > If we do a switch like the above, > we'd have to make sure that at least the exception values are checked > before conversion. Yep. > Actually, that's not even required. All you'd have to take care of > is that > bint becomes 0/1 when coercing to a non-bint type. That could simply > include other int types in the future, so that > > cdef int i = 0 > cdef bint x = 5 > i = x > > would be guaranteed to set i to 1, whereas x would still be 5. I think it makes much more sense (if we do it) to convert to 0/1 when converting *to* a bint type, rather than from it. > I'm not sure how this would apply to comparisons, though, such as > > cdef bint x = 5 > cdef int i = 5 > cdef bint result = i == x > print result > > should that print False (being evaluated as 'int'), or would the > comparison > use the bint type and return True? The natural widening is bint -> int. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
