Robert Bradshaw, 11.07.2010 00:00: > On Sat, Jul 10, 2010 at 2:45 PM, Dag Sverre Seljebotn wrote: >> On 07/10/2010 09:11 PM, Stefan Behnel wrote: >>> Robert Bradshaw, 09.07.2010 17:29: >>> >>>> For the moment, though, I'm wondering why we even bother letting >>>> people declare the type as bool--it's not a very useful (Python) type >>>> to statically declare, but can cause a lot of confusion. >>>> >>> Agreed, use cases are hard to come up with. However, given that it's there, >>> I'd prefer keeping the C++ type in a separate namespace for now and >>> maybe(!) improve Cython warnings to find common traps when compiling in C++ >>> mode. >>> >> >> But int and float has the exact same problem! And there we inherited C >> semantics from Pyrex... > > And, for Py2, long has a double meaning as well. There is very little > use (currently) for declaring things to be Python ints, longs, floats, > bools.
Well, 'long' is exactly the reason: Since there are 'int' and 'long' in Py2, which are completely interchangeable, it's impossible to type a variable as Python 'int' or 'long' without restricting your code too much. If you type it as 'int', a C int will behave much better as it accepts both Python integer types. If there was only Py3 (with only one Python 'int' type), this problem would have occurred much more often (and I predict that it will become more apparent when more people start developing Py3 code). 'float' is different here as there is no redundant type in Python, but since 'float' is equivalent to C double, there's no reason not to type your variable as a C double directly. Also, it'll actually work to declare your variable as 'float' if you only pass Python floats. But it won't necessarily do exactly the right thing. In general, numeric types are much less of a problem as they have well defined coercion semantics. The boolean types of C, C++ and Python do not. >> Therefore C++ bool makes sense IMO, to be consistent with int and float > > Yep. The main problem that I see is that most of the usecases for bool > will be wrong, resulting in compiling, running code that does the > wrong thing. I'd rather not have the type at all. Actually, now that I think some more about it - Cython 0.13 moves many Python types into C space automatically, so we may consider *always* mapping 'bool' to the native boolean type in the target language. Python's 'bool' type is compatible with integers anyway, so we could map 'bool' to a 0/1 restricted bint in C and bool in C++ (assuming appropriate coercion semantics for C++/Python). Ok, the bool type in C++ isn't compatible with integers, but I think that's only a minor issue. The only case where you'd really see this is when you try to add a 'bool' to an integer. This has no impact on Python compilation or pure Python mode, and it's not hard to explain to someone who wraps C++ that 'bool' is really C++ bool. We could still make all three types available through separate cimport namespaces. Stefan _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
