Robert Bradshaw wrote:
> On Nov 10, 2008, at 9:54 PM, Stefan Behnel wrote:
>> @cython.cexttype(attr1=type, ...)
>> class A:
>> ...
>
> I would prefer cython.cclass(...) or cython.extension_type(...)
> [...]
>> people who know C might be happier with @cython.static or
>> @cython.cfunc.
> [...]
>> @cython.fastccall
>> def myfunc():
>
> Or maybe even "ccall" as the fast should be obvious.
I like how simple "cclass" is, and how well it matches "cfunc" and "ccall".
So what about
@cython.cclass(attr1=cython.int, ...) # Py3 only
@cython.cfunc(cython.int, arg1=cython.int, ...)
@cython.ccall(cython.int, arg1=cython.int, ...)
I think they target nicely distinct use cases and make it perfectly clear
what's happening. Additionally, you can use
@cython.locals(var1=..., ...)
with @cython.cfunc, @cython.ccall or plain functions. Not sure if we
should allow declaring function parameters in the cfunc/ccall cases. It
makes sense in the plain function case, though.
Now I don't even see a use case for
@cython.returns(cython.int)
anymore, as all functions where it makes sense would either be ccall or
cfunc.
>> (BTW, should such a class - be allowed to or automatically -
>> inherit from object in Python?)
>
> Don't all types inherit from object already?
No, only in Py3. In Py2, if you write
class A: pass
you will get an old-style class. I would love to rule that out for classes
that Cython will compile to cdef classes.
>> 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.
Well, the difference is that the above gives you a class attribute in
Python, which users usually (but not necessarily!) overwrite by instance
attribute setting in the constructor. In any case, it stays alive in the
class and can be accessed there, be it through the instance or the class.
However, for extension types, the attribute is /always/ per instance.
> I like
> being able to specify the attributes in the decorator as well though.
Yes, I think the above syntax gets more readable the more attributes you
have, but the decorator/metaclass syntax allows you to keep Python
semantics.
>> 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).
Yes, it would match the decorator exactly.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
