Robert Bradshaw, 08.12.2009 00:41: > I'm not a fan of the current interface. What I think would be more > useful is > > cython.infer_types(True) # explicitly enable it everywhere. > cython.infer_types(False) # explicitly disable it everywere, > including "safe" inference. > cython.infer_types(None) # the default, "safe" inference. What > this actually means may change over time, but the semantics of the > resulting code shouldn't.
I switched to strings as I imagined that we may have to support other values as well, such as a list of single type names or a name for a group of types. But all of that isn't easy to support with the current directive parsers anyway. So, if we ever want to support that, we can just as well allow keyword arguments as in "infer_types(True, bint=False)". (I love keyword arguments) >> I'm not against "bint" always being 0 or 1 in general though, so that >> >> cdef bint x = 3 >> >> turns into >> >> cdef bint x = (3 != 0) >> >> and >> >> cdef extern bint foo() >> x = foo() >> >> turns into >> >> __pyx_v_x = (foo() != 0); > > 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. If we do a switch like the above, we'd have to make sure that at least the exception values are checked before conversion. >> But, it should be completely orthogonal to type inference! > > Yep. ... except that it would broaden the niche of safe type inference a bit. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
