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).
The point of locals is to declare the types of local variables, orthogonal to the question of whether or not it is a cdef/cpdef/ect. function. > 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 Yes, I certainly want to support this form as well, but it's only for Py3+ (or even if it's in 2.6, that's not old enough). > "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. cython.cpdef would be a bad fit for a def function(that has typed local variables). There should be a decorator for calling convention (def/cdef/cpdef) and a decorator for locals. Both can declare what the argument types are. > 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. Yep. > Then you could have chained argument decorators: Yes. > > @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. ?? One issue with calling conventions is that one wants to be able to share them across modules/use them in classes (and subclasses), etc. Until we have automatic .pxd creation, this will be hard to do with decorators alone. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
