Stefan Behnel wrote:
> Hoyt Koepke wrote:
>>>> I kinda like the idea of having two types that are only really
>>>> different in corner cases like these, e.g. cint , clong, (maybe int,
>>>> long), and that these are an explicit request for c semantics in every
>>>> way. Other types like int (maybe py_int?) are a request for python
>>>> sematics, even if it means a slight speed penalty over c semantics.
>>>> Making this distinction explicit would seem to make everyone happy --
>>>> both the python coders who want speed and the c coders who work in
>>>> python -- though it would probably mean more work for the cython
>>>> developers. It also seems like more of a long-term solution, as there
>>>> are other cases this would resolve (like overflows in c but not
>>>> python).
>>> Ooh, I definitely like this idea.
>> Thanks.
>>
>> It seems like the only places where this matters are with integers.
>> Thus if cython had one type, say py_integer (to distinguish it from
>> PyIntObject*, like you mentioned), which in the C code would be a long
>> or long long, but the semantics in the generated code would always be
>> determined by python syntax.
>
> But you can't emulate the Python int semantics without also adding
> arbitrary size values. So, where would you draw the line? And how would you
> explain to users why this type has part X of Python's int semantics but not
> part Y, and why this type exists at all?
>
> I'm afraid of the complexity that this duplication of type names adds to
> the language.
>
> Plus, it does not solve the problem at hand, which is a problem with the
> semantics of an operator and not with the semantics of a type.
Well, strictly speaking, Python % etc. means "invoke __mod__"; and
different classes can do different things (indeed NumPy uses C
semantics; for speed I presume). So it's not true that types and
operators are orthogonal in language design.
To make this more concrete, we already have a syntax aimed more at
Python users speeding up code:
@cython.locals(x=cython.int)
def f(x):
return x % 3
So "cython.int" and friends could assume Python behaviour. BTW I'm not
proposing that the @locals has anything to do with it,
def f(cython.int x): return x % 3
should have Python semantics as well, it is just mixing coding styles
and not what one is likely to see...
Then one could add cython.cint to correspond directly to a C int.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
