[Cython] Utility Codes and templates
Dag Sverre Seljebotn
d.s.seljebotn at astro.uio.no
Fri Jul 22 13:31:48 CEST 2011
On 07/22/2011 01:10 PM, Stefan Behnel wrote:
> mark florisson, 22.07.2011 12:12:
>> For my work on the _memview branch (and also on fused types) I noticed
>> that UtilityCodes started weighing heavily on me in their current
>> form, so I wrote a little loader in the _memview branch:
>> The idea is simple: you put your utility codes in Cython/Utility in
>> .pyx, .c, .h files etc, and then load them. It works for both
>> prototypes and implementations, for UtilityCode and CythonUtilityCode:
>> // UtilityProto: MyUtility
>> header code here
>> // UtilityCode: MyUtility
>> implementation code here
>> You can add as many other utilities as you like to the same file. You
>> can then load it using
>> UtilityCode.load_utility_from_file("myutility.c", "MyUtility")
> Why not have exactly one per file? They can't (or at least shouldn't) be
> interdependent anyway, since they're always loaded and injected
> separately. Having one per file makes it easy to take the file name and
> grep for it.
>> Of course you can pass in any other arguments, like proto_block, name,
>> etc. You can additionally pass it a dict for formatting (for both the
>> prototypes and the implementation)
> Dict? Why not keyword arguments?
> I'd prefer an interface like this:
> some_format_arg="somename", some_repeat_arg = 2)
> That would automatically look up the corresponding files
> and take whichever it finds (first), then run the template engine on it.
> I don't think we need to support separate arguments for prototype and
> code section, they can just use different names. Keep it simple.
>> It will return a UtilityCode instance ready for use.
>> You can also simply retrieve a utility code as a string, where it
>> returns (proto, implementation).
>> As debated before, an actual template library would be really
>> convenient. Dag and I had a discussion about it and he suggested
>> Tempita (by Ian Bicking), it is compatible with Python 2 and Python 3,
>> and is pure-python. It supports all the good things like iteration,
>> template inheritance, etc. Now I'm not sure whether it supports python
>> 2.3 as it doesn't compile on my system, but it does support 2.4
>> (confirmation for 2.3 would be appreciated). On a side note, I'd be
>> perfectly happy to drop support for 2.3, it's kind of a chore.
>> The documentation for Tempita can be found here:
>> That way we might rid ourselves of a lot of code.putln() and move
>> those to template utilities instead (or at least prevent writing more
>> of those). What do you guys think?
> I'm fine with using a template engine for the more involved cases (which
> are rare enough). However, I'd prefer not adding a new dependency, but
> just shipping a tiny single-module engine with Cython, e.g. Templite or
> pyratemp (just found them, never used them).
Tempita *IS* intended to be a "tiny single-module engine". Well, it is
spread across several source files, but it wouldn't be intrusive to
merge them into one file (if that's the qualififying criterion).
I submit that:
a) For the templating we need, there's probably a dozen out there that
are "good enough" and small and simple.
b) So, there's not any point in spending valuable time finding the
"optimal solution". Good enough is good enough.
c) Still, we shouldn't pick one at random, because there might be a
subtlety that makes it impracticaly in real world usage.
Thus, I think there's a strong case for going by personal recommendation
by somebody who's actually used something, and just go with that.
If anybody else has used something else and is happy with it, I'm happy
with going with that instead. Tempita:
- Is small enough for bundling
- Has the recommendation of me and Robert Kern (earlier on this list)
- Has been used by me for doing a bunch of templating in Cython, C and
> There's a whole bunch of engines listed here:
> cython-devel mailing list
> cython-devel at python.org
More information about the cython-devel