On Nov 11, 2008, at 1:22 AM, Stefan Behnel wrote: > 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.
I think that's fine, there's going to be a lot of cases where one only cares about typing the arguments (especially once we have type inference). > 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. Yep. >>> (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. Ah, classes (not extension classes). I think we should retain the Py2 behavior in Py2. But @cython.cclass class A: pass would necessarily inherit from object. >>> 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. Yep. I also like how it's a direct analogue of the "cdef int attr1" that we use now (in case anyone's translating old code to be use in pure Python mode). >> 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. OK. lets to that then. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
