[Cython] Utility Codes and templates
markflorisson88 at gmail.com
Fri Jul 22 13:45:46 CEST 2011
On 22 July 2011 13:31, Dag Sverre Seljebotn <d.s.seljebotn at astro.uio.no> wrote:
> 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
> Fortran code
> Dag Sverre
+1, it looks pretty neat to me.
>> There's a whole bunch of engines listed here:
>> cython-devel mailing list
>> cython-devel at python.org
> cython-devel mailing list
> cython-devel at python.org
More information about the cython-devel