Sturla Molden wrote: > There is a big source of inconsistency here. First, there is no such thing > as an unsigned Python int, a Python char or a Python short.
No-one is questioning that. Please read the subject of this thread. > Explicitely declaring Python types is fine. But then this should be > restricted to actual Python types! Not try to make 25% of C types > Python-like, and leve the rest to behave as in C. Now we get a complete > mess of C and Python semantics, never knowing what we get. There should be > a clear distinction between Python objects and primitive C types. There is a very clear distinction between all types, including Python types and C types. The internals are not always simple, but the syntax is and the semantics tries to be, which is the thing that matters. This discussion is not about right or wrong, it's about good semantics that matches the expectations that users have of the language. Semantics that keeps users from getting things wrong because of bad language design. And it's about a trade-off between expected semantics and performance, which is what makes this tricky. It's also a discussion about the design goals of Cython, which, I assume, is the reason why people are having very strong opinions on this. > Further, Python as an official way to make type annotation. The annotations in Python 3 are by no means as powerful as the ones in Cython. So this argument is not very convincing. > If Cython > wants to be as Python-like as possible, use the f*cking Python 3 type > annotations - don't use cdefs. May I ask you to rethink your wording? > Making a statically typed Python and braking C is very different. And the > Cython team is breaking C. The correct word is "generating" here. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
