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:
...
(BTW, should such a class - be allowed to or automatically - inherit from
object in Python?)
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...
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.
> 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.
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.
> 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():
> 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):
Saving one line of code isn't always worth it, and declaring return types is
not as common as declaring local variables.
> 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.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
