On Mar 11, 2008, at 2:30 AM, Stefan Behnel wrote: > Hi, > > Dag Sverre Seljebotn wrote: >>> Yeah, it could get ugly: cython.types.pointer(cython.types.pointer >>> (cython.types.int))." >> >> I think "cython.types" is too longwinded anyway, in practice it >> would be: >> >> import cython.types as c > > wouldn't that have to be > > cimport cython.types as c > > ? > > Although that would break Python compatibility again, right? > > That's somewhat unfortunate... > > BTW, what would be provide to keep up Python compatibility anyway? > Would there > be a fake importable package like this just to make the code work > in Python? > You'd have to ship that with you Cython/Python code, then ...
Yep, there'd be a "fake" cython module that one could import. It would be cool if it could actually do ctypes to emulate some of the stuff before actually compiling. I don't really see any way of providing the rich set of names we need to make executable python code that can also be compiled. >> 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. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
