I'd like to release this soon. I've changed declare so it can work as below (i.e. declare(var=type, ..)). For now there's no "cpdef/ cdefclass/earlybind/??" decorator, we'll hammer that one out later. Any other comments before we commit to it?
- Robert On Oct 6, 2008, at 2:39 PM, Dag Sverre Seljebotn wrote: > Robert wrote: > ... >>> E.g. having the option to write pure C functions (and classes). >>> Maybe >>> something like: >>> >>> @cython.locals(g=int, x=int) >>> def g(x): >>> return x+5 >> >> Exactly how to do this with decorators (and/or automatically) is less >> clear (syntax-wise, and there are more technical issues about >> signatures matching, etc.). What you can do is write an >> accompanying .pxd file which will, of course, be ignored by Python, >> but can declare cdef classes/methods/etc for Cython. Then your class >> and def statements will be appropriately coerced when you compile. > > Syntax-wise this might be an argument against the name "locals" (and > before a release is done there is still time to change it). > > a) With another name, it could be possible to make the return value > of the > function the first positional argument. (I.e. a name that means > "@cython.cpdef", rather than only affecting the locals as such, but is > more descriptive). > > This is assuming the "cdef/cpdef/def" can be decided automatically > (something like make everything cpdef and for pointer argument/return > types either introduce ctypes coercion or a stub raising a runtime > error > when invoked from Python). > > b) I think it makes sense to eventually add support for Py3 argument > decorators as well: > > @cython.locals > def g(x: cython.int): > return x + 5 > > "locals" is a bad fit for this. Of course, one would select another > name > for this than the "locals" we have, however that is one more > decorator to > learn without any obvious advantages over a concept like > "@cython.cpdef" > which could conceptually fit in both situations. One could also > drop the > function decorator, but this is rather unfriendly if you use other > decorators in the same program: > > def g(x: cython.int): > return x + 5 > > def f(x: "The input number"): > return x + 5 > > def modify_docstrings_on_module_functions(): > # must now strip cython types... > > So I think there should be a decorator on a function when you > decide to > Cythonize it. Then you could have chained argument decorators: > > @cython.cpdef # or whatever > def g(x: (cython.int, "The input number")): > return x + 5 > > and have the cython.cpdef decorator process the argument decorator > tuple > and replace it with the second item, which can then be processed by > Python > code. > > Dag Sverre > > _______________________________________________ > 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
