Lisandro Dalcin wrote:
> On Tue, Nov 3, 2009 at 2:12 PM, Dag Sverre Seljebotn
> <[email protected]> wrote:
>
>> Lisandro Dalcin wrote:
>>
>>> On Tue, Nov 3, 2009 at 1:06 PM, Dag Sverre Seljebotn
>>> <[email protected]> wrote:
>>>
>>>
>>>> Lisandro Dalcin wrote:
>>>>
>>>>
>>>>> On Tue, Nov 3, 2009 at 7:20 AM, Robert Bradshaw
>>>>> <[email protected]> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Nov 3, 2009, at 12:45 AM, Dag Sverre Seljebotn wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Robert Bradshaw wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> There's
>>>>>>>> another regression, "cdef int complex" doesn't work anymore (our
>>>>>>>> structs used to support this, as does gcc, even if it's non-c99).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Turns out this broke nearly all my own code :-( I'll give a proper
>>>>>>> solution a go.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Thanks! It think it should be pretty easy (probably can use the type
>>>>>> name, rather than the math postfix marker to name the methods...)
>>>>>>
>>>>>> http://trac.cython.org/cython_trac/ticket/446
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Or use other approach for handling "int complex" types. Honestly, I
>>>>> did not take into account this use case.
>>>>>
>>>>> Mmm... I'm thinking that trying to support (floating) complex in C89
>>>>> is not a good idea, some things are really hard to do (if ever
>>>>> possible)...
>>>>>
>>>>>
>>>>>
>>>> Huh? Do you mean what's there already?
>>>>
>>>>
>>>>
>>> No, just the "Seamless" support... I mean, if the 'ccomplex' directive
>>> is not on, then make Cython generate an error when external ctypedefs
>>> are used, and any other situation where there is ambiguity...
>>>
>>>
>> Hmm. I don't think C89 complex is really the problem. There's plenty of
>> similar problems like the functions for integer division and (in future)
>> overloaded functions.
>>
>> Dag Sverre
>> _______________________________________________
>> Cython-dev mailing list
>> [email protected]
>> http://codespeak.net/mailman/listinfo/cython-dev
>>
>>
>
> Do you remember that I advocated for "ctypedef some int MyInt" or
> something similar? If right now we had that, Cython could reject some
> things, like binops on different "ctypedef some .." types, requiring
> users to introduce casts to resolve the ambiguity... A said it before,
> and I say it again: second-guessing is a bad thing (or, in Python's
> Zen words: "In the face of ambiguity, refuse the temptation to
> guess.")
>
I remember very well, and I've been thinking about it the whole day. I
wholeheartedly agree with you that the situation is not good.
Another, perhaps more "backwards-compatible" approach is
(backwards-compatible in the following sense: It will break code that
should be broken and fixed, and not suddenly introduce bugs that are
hard to find):
a) Tighten down everything so that explicit casts are needed even for
stuff like this:
cdef long i
cdef external_typedef_int j
print i / j # not allowed, must do i / <long>j
b) Add "exact" instead of "some"
cdef extern ...:
ctypedef long! mylong
Code is then inserted during module loading which ensures sizeof(long)
== sizeof(mylong).
However I seem to remember that this was rejected as well by Robert
(who, for some reason I can't understand, seems to think the current
situation is OK.)
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
