On Tue, Nov 3, 2009 at 3:06 PM, Dag Sverre Seljebotn <[email protected]> wrote: > 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 >
OK, +1 on this... > > b) Add "exact" instead of "some" > cdef extern ...: > ctypedef long! mylong > Well, I'm still thinking that "ctypedef int MyInt" should actually mean exact... However, I realize that this is going to be a source of code breakage. > Code is then inserted during module loading which ensures sizeof(long) > == sizeof(mylong). > Mmm... Do "ensure" means a import failure? Perhaps a warning would better? Perhaps a mismatch does not necessarily means the code is broken... > 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.) > Perhaps we were not clear enough at that time, and Robert rejected the idea because it introduced new syntax? -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
