On Nov 5, 2008, at 6:52 AM, Ondrej Certik wrote: > On Wed, Nov 5, 2008 at 2:52 PM, Stefan Behnel <[EMAIL PROTECTED]> > wrote: >> Ondrej Certik wrote: >>> one drawback is that I still need to use .pxd files to >>> declare cdef functions. Example: >>> >>> @cython.locals(n=cython.int) >>> def fact(n): >>> ... >>> >>> in order for this to become a "cdef int foo()" function, I need to >>> have this line in foo.pxd: >>> >>> cdef int fact(int n) >>> >>> (And then the @cython decorator is not necessary). I'd like to have >>> everything in the .py file.
Certainly this is a goal of mine too. It was (IMHO) less straightforward the best syntax to use, and I wanted to get the other stuff out there for testing/trial first. Until we have autogenerated .pxd files, or the equivalent, this won't allow one to share cdef classes/methods. >>> Could that be approached by for example >>> something like: >>> >>> @cython.locals(n=cython.int, _return=cython.int, cdef=True) >>> def fact(n): >>> ... >> >> That would block calling a local variable "cdef", which would be >> valid >> Python. Calling it _cdef might solve this, but having "_return" >> blocked >> already is bad enough. >> >> How about a generic decorator @cython.cdef ? >> >> @cython.cdef >> @cython.locals(n=cython.int, _return=cython.int) >> def fact(n): >> ... >> >> would become >> >> cdef int fact(int n): >> ... > > Yes, that looks perfectly ok. And the same for extension classes. Dag mentioned an "earlybind" rather than "cdef" as it would have more meaning to newcomers. There's also the issue of cpdef vs. cdef, should that be a flag to the decorator, or a new decorator. I'm not a fan of the _return parameter, I think it belongs in the "cdef" decorator as it doesn't make sense without it. It would be nice if one could declare argument types there as well (though that introduces some redundancy with locals). Perhaps the first (prepositional) argument would be the return type. There's also Py3 syntax for annotating arguments, though I think we'll be wanting to support Py2 for quite a while. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
