BTW as you may have gathered I may have misunderstood your original request; if you would rather like to implement Stefan's original (and, I believe, complementary) proposal then the procedure is a bit different. But ask for details if you want to take that route...
Dag Sverre Seljebotn -----Original Message----- From: "Ondrej Certik" <[EMAIL PROTECTED]> Date: Friday, Sep 26, 2008 5:13 pm Subject: Re: [Cython] Support .pxd files for plain Python source files? To: [EMAIL PROTECTED]: [email protected] On Fri, Sep 26, 2008 at 4:43 PM, Dag Sverre Seljebotn ><[EMAIL PROTECTED]> wrote: > If you have a couple of evenings I'm happy to help with pointers as it would > be a good investment of time. > >> I can write more later when I'm not on my phone, but: I'd suggest starting >> with implementing > >> @cython.earlybind > def f(x, y): ... > >> and have it turn to > >> cpdef f(x, y): ... > >> (note on the name below) > >> Just getting this working, with arguments and result typed to "object", >> should get your feet wet. Then I suppose the next step is implementing the >> Py3 PEP supporting decorators on arguments and return type. (I think one >> should aim for Py2.6+ here, though I suppose arguments to the decorator >> could work too: @cython.earlybind(x=cython.uint, >> localvar=cython.float)...opinions? > >I need it to be working with python2.4+, so I'll choose something that works >in python2.4. Debian just switched to python2.5 recently, so >it's a long, long way before python2.6 could become a de facto >standard. But generally I agree one should design this so that things are >especially easy in python2.6+. > >> > Brief scetch on the first step anyway (please ask about any hazy points and > I'll give better help when I'm at a computer): > >> 1) The file you want to work in is ParseTreeTransforms.py. Your goal is to >> intercept decorated DefNode-s and transform them into CFuncDefNodes. Have a >> look and see how transforms are written... > >> 2) The ResolveDirectives transform (or something like that) already has code >> in it to intercept @cython.X-decorators on functions for compiler >> directives, I think you want to extend that transform, in time changing the >> name appropriately to give it a wider scope. > >> 3) the general workflow is this: Create a small testcase with both "from" >> code and "to" code as given above. Then add this function to >> ResolveDirectives (not entirely sure about the node class name, see >> Nodes.py): > >> def visit_CFuncDefNode(self, node): > print node.dump() > return node > >> this gives you an idea about the node structure you must convert to. > >> 5) To transform, edit the function visit_DefNode to also take into account >> "earlybind" (hardcode it) before checking the decorator against directives, >> and if so, simply set node = self.convert_def_to_cpdef(node), which you >> write. "node.dump()" here gives you the from-tree. > >> 6) if you fancy unit tests in addition to integration tests, have a look at >> TestWithTransform.py (or similar) for how to do it. You should literally be >> able to input the decorated def example above as a string and assert that >> the result after the transform is the expected cpdef version... though you >> may need to extend CodeWriter.py to serialize cpdef to strings. > >> Send an email whenever something is not obvious -- it would be really cool >> to see this in Cython. > >> Note on names: It is easily changeable so it is not a big point...but here >> goes: I think personally the cdef and cpdef are very cython-specific and >> communicate badly with python users. Also, considering cpdef exists, I think >> the need for cdef should be small? If wanted it could be called >> "@cython.nativeonly" perhaps. Anyway, "earlybind" also gets in the important >> message that you cannot reassign the symbol it binds to at runtime, which is >> a difference with how you expect a "def" to work. > >Thanks a lot for the help! I'll give it a shot and report back. > >Ondrej >_______________________________________________ >Cython-dev mailing list >[email protected] >http://codespeak.net/mailman/listinfo/cython-dev > _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
