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. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
