On Mar 11, 2008, at 3:24 AM, Stefan Behnel wrote: > Hi, > > Robert Bradshaw wrote: >> On Mar 11, 2008, at 2:30 AM, Stefan Behnel wrote: >>> Dag Sverre Seljebotn wrote: >>>> c.ptr(c.ptr(c.int)) >>>> >>>> Which isn't *that* bad? And one could provide all kind of >>>> convenience >>>> pre-declared names: >>>> >>>> c.pint = c.ptr(c.int) >>>> c.ppint = ... >>>> c.pchar = ... >>>> c.ppchar = ... >>>> >>>> Perhaps just make a convention of providing up to three "ppp"- >>>> types for >>>> every type, and then have a parametrized type >>>> >>>> c.ptrs(6, c.int) >>>> >>>> if you really want to do int******. >>>> >>>> PChar is already a well-known synonym for char* in some codebases. >>> >>> +1 here, although I'd call it "p_int" and "pp_int" instead of a >>> good ol' >>> "pint". :) >>> >>> And c.ptrs() is better written as "c.pointer(c.int, levels=6)" >>> and maybe >>> DEF-assigned to a name somewhere in the code. >> >> I see all this stuff as syntactic sugar that wouldn't usually get >> run, >> rather they would be compiler hints. > > Hmm, I think it should be more. I was considering them to be type > references > that Cython would look up in a separate type module at compile > time. You could > even integrate compile-time factories that would return Cython > types when > called by the compiler. The decorator notation gives you all sorts of > possibilities to interact with Plugins already, so this would just > be one step > further.
I agree that types wold be a good thing to look up that could be the same module in several cases. As for the decorator notation, in one case it would be passed a function object, and in another it would be passed a parse tree. One could write them to take either, but at the lowest level they still get turned into compiler hints (tree transformations to run being seen as one such hint). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
