StaticTuple... naming, maintenance, ...
INADA Naoki
songofacandy at gmail.com
Tue Oct 6 01:40:16 BST 2009
> 3) C/Cython/Pyrex
> The #1 memory benefit is removing the python GC header from all of
> the objects. (16 bytes / object.)
> I can easily define such a type in C, and have done so.
>
> However, as you get into doing more with these objects, (like
> creating a C level api to share with other code), there is a *lot*
> more maintenance overhead in doing it from C.
>
> You have to do all the exception handling manually, *and* write all
> of the boilerplate for exposing the dynamic loading of functions.
> In Pyrex/Cython doing so is:
>
> cdef object myfunc(object):
>
> becomes
>
> cdef api object myfunc(object):
>
> Doing so in C is about 4 lines of boilerplate per function, type
> checking, etc. Plus another 20+ lines that you have to write to
> describe that you *have* a C api that should be loaded.
>
>
> In the end, I wrote "StaticTuple" in C, and "StaticTupleInterner" in
> Cython, and the latter took a day, and the former took a week. It is
> a "sunk cost", but ongoing maintenance is not.
>
> The main issue here is that Pyrex will not generate objects without
> the HAVE_GC flag set. Cython >= 0.11 can (as long as you don't have
> 'object' attributes, which is true here, because I have to use
> PyObject** because neither Pyrex nor Cython support C arrays of
> objects)
>
> The difficulty is that would be a hard jump to go from Python 0.8 or
> so (doesn't even support +=) to Cython 0.11 (it is in Karmic, but
> Jaunty only have Cython 0.10).
>
> I would *really* like to switch to Cython 0.11+, as I have specific
> benefits. One could argue that we could try to be compatible, and
> people can compile using Pyrex, and just wouldn't get the memory and
> speed improvement of avoiding the GC...
>
> I'm also using stuff like 'cpdef' and 'inline', but I can work
> around those things easily enough. I can't hack the 'HAVE_GC' flag
> easily.
>
I think installing Cython to local is not a big problem.
And I love Cython, too.
--
Naoki INADA <songofacandy at gmail.com>
More information about the bazaar
mailing list