On Nov 10, 2008, at 9:54 PM, Stefan Behnel wrote: > Hi, > > Robert Bradshaw wrote: >> On Nov 5, 2008, at 6:52 AM, Ondrej Certik wrote: >>> On Wed, Nov 5, 2008 at 2:52 PM, Stefan Behnel wrote: >>>> @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. > > Extension types are a different thing and behave different from cdef > functions. I'd prefer having a separate decorator for them, > something like > > @cython.cexttype(attr1=type, ...) > class A: > ...
I would prefer cython.cclass(...) or cython.extension_type(...) > (BTW, should such a class - be allowed to or automatically - > inherit from > object in Python?) Don't all types inherit from object already? > I'm not sure the attributes are necessary, though. It might be > enough to write > > @cython.cexttype > class A: > attr1 = cython.declare(cython.int) > ... > > But the problem is that this has different semantics in Python... The semantics are not different enough to be a bad syntax. I like being able to specify the attributes in the decorator as well though. > Given that class annotations are not really a current Python thing > anyway, I > might also consider > > a) a special Cython metaclass > > class A: > __metaclass__ = cython.cexttype > > >> > or b) simply use inheritance > > class A(..., cython.CExtType): > > where cython.CExtType 'is' object when running in Python. Both of these are interesting, but I have to say I prefer the decorator form, but it's not available < Py3. The __metaclass__ seems to fit what's happening better (and could also take attribute/other arguments). >> Dag mentioned an "earlybind" rather than "cdef" as it would have more >> meaning to newcomers. > > I actually like @cython.cdef, but only for functions. In Python, it > conflicts > too much with the 'def' keyword. Yeah, it doesn't make as much sense for classes. > OTOH, people who know C might be happier with @cython.static or > @cython.cfunc. > That would also make it clear why the function disappears from the > module > namespace when compiled. Static means to many (different) things in too many languages. I like cfunc. @cdef def seems rather redundant and meaningless to non-cython people. >> There's also the issue of cpdef vs. cdef, >> should that be a flag to the decorator, or a new decorator. > > Hmm, good question. What about > > @cython.def(fast_c_call=True) > def myfunc(): > > as an equivalent to cpdef? I think that makes it perfectly clear > what cpdef > does. Maybe this is enough: > > @cython.fastccall > def myfunc(): Or maybe even "ccall" as the fast should be obvious. I think passing in a keyword argument gets to verbose, and I'd like to use that to type arguments as well. I'm still in brainstorming mode, as I'm not totally happy with any of the options we have come up with so far. >> 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. > > The idea of a first positional argument for the return type totally > makes > sense to me. The only problem here is that this makes @cython.locals > () a > non-intuitive name, as the return type is everything but local. > > @cython.locals(cython.int, a=cython.float, ...) > def myfunc(a): > > Why not use a separate decorator > > @cython.returns(cython.int) > @cython.locals(a=cython.float, ...) > def myfunc(a): +1 > Saving one line of code isn't always worth it, and declaring return > types is > not as common as declaring local variables. I locals is for typing all local variables, it just so happens that function arguments are local variables as well. I think the same decorator used to declare the function c[p]def should take an (optional) argument specifying the return type, as well as be able to type arguments if desired. >> There's also Py3 >> syntax for annotating arguments, though I think we'll be wanting to >> support Py2 for quite a while. > > That's more than a nice-to-have, though. I think if we make it into > the > stdlib, it's most likely to get there somewhere in the Py3 series. So > supporting this would be consistent with the language level by the > time. > > Note that this would only impact @cython.locals (and > @cython.returns), the > rest would still be required. So the Cython Py2 annotations and the > official > Py3 function annotations are actually orthogonal, and we should > support both > in Py3, as people might want to use their function annotations for > other stuff > as well. Yep. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
