[Cython] Utility Codes and templates

[mark florisson]

On 22 July 2011 13:10, Stefan Behnel <stefan_ml at behnel.de> 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:
>>
>>
>> https://github.com/markflorisson88/cython/commit/e13debed2db78680ec0bd8c343433a2b73bd5e64#L2R110
>>
>> 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:
>>
>> myutility.c
>>
>> // 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.

Putting them in one file does not make them interdependent, they are
still loaded separately. Once the first utility is loaded from the
file, it loads all the utilities as strings from the file and caches
them. You don't want to enforce one utility per file as many utilities
are pretty small, and you want to group utilities based on their
purpose. (r)Grepping will be just as easy. You may still want to pass
the filename as you might want a .c and a corresponding .h (or a .pyx
and a corresponding .pxd), or simply one .pyx and one .c, one for the
Cython utility code and one for the C utility code.

Of course, we could introduce a method load_utility() which takes just
"MyUtility" and loads it from MyUtility.*, whichever one it finds
first.

>
>> 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?

Because (Cython)UtilityCode already takes a bunch of keyword arguments
and you want to keep them separate. In any case you could always add
whatever convenience method you want. I'll add one to pass in
arguments like that.

> I'd prefer an interface like this:
>
>  UtilityCode.load_from_file("myutility",
>          some_format_arg="somename", some_repeat_arg = 2)
>
> That would automatically look up the corresponding files
>    Cython/UtilityCode/myutility.{pyx,c,cpp,h}
> 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.

Sure, that's also fine.

>
>> 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:
>> http://pythonpaste.org/tempita/
>>
>> 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).

It's far from rare, you could then use it not only for utility codes,
but for general code generation.

> http://www.joonis.de/content/TemplitePythonTemplatingEngine
>
> http://www.simple-is-better.org/template/pyratemp.html
>
> There's a whole bunch of engines listed here:
>
> http://wiki.python.org/moin/Templating
>
> Stefan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>