Robert Bradshaw wrote: > On Dec 7, 2009, at 11:30 AM, Stefan Behnel wrote: > >> Robert Bradshaw, 07.12.2009 18:53: >>> On Dec 6, 2009, at 2:30 PM, Stefan Behnel wrote: >>>> Robert Bradshaw, 03.12.2009 18:10: >>>>> Nice. With that, I can't see any place that inference of doubles >>>>> wouldn't be safe either, and it would be very convenient. >>>> ... what about 'bint'? Now that and/or behave as expected, would >>>> that type >>>> be safe to infer, too? >>> What about >>> >>> x = 5 >>> x = True >>> print x >> That would unexpectedly print '1', I guess. But we could special case >> 'bint' in the type inference algorithms so that it won't be >> compatible with >> any other int type. So if you do the above, x will turn into a Python >> object instead. > > Special casing bint for safe mode seems reasonable. > >> There's another case that I came up with. Since True/False are >> specified to >> be equivalent to the int values 1/0, there's likely some code out >> there >> that does this: >> >> cdef bint func(x): >> ... >> return 2 # also 'true' in C >> >> true_values = 0 >> for i in range(10): >> true_values += func(i) >> >> This currently coerces the return value to True and then adds its >> integer >> value 1 to true_values. But I'm actually fine with breaking that >> kind of >> weird code... > > Yeah, that's not breaking valid Python code at least. If your code is > depending on the subtleties of non-identity C/Python conversions, then > you're asking for trouble to have any kind of inference at all, and I > don't thing this is a worthy enough use case to not enable safe mode.
I'm growing worried here. Will there be three levels of inference (none, safe, full) exposed to end-users? That's way too complicated in my opinion. The point of "safe" inference is that they can be done by default, without users having to know anything about it (except that some more code just run faster). If you have to actually read the manual to understand it and turn it on, you might as well use the full mode. 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); But, it should be completely orthogonal to type inference! -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
