[capink]

Originally Posted by chaley

I think the chances of using a python template in an EvalFormatter context are zero. The EvalFormatter isn't given an mi but instead a key:value dict.
This would require the template processor to examine the argument signature to figure out what arguments to pass, something like java introspection. By definition this requires knowledge of the semantics of the arguments. I don't see how to do this with reasonable effort.

Here is what I am thinking. You would create a python template that looks something like this:

python:
def evaluate(mi, db):
    # python code as needed, for example, this nonsensical program
    if len(mi.authors) > 5:
        return 'Too many authors!'
    # db is an instance of db.legacy().
    # You can get an instance of db.cache using the attribute db.new_api
    # You can get an instance of db.view using the attribute db.data.
    ids = db.data.search_getting_ids('series:true') 
    if len(ids) > 100:
        return 'Too many books in series!';
    return 'All OK :)'

The template processor would compile this into a class as described above, then execute the "evaluate" method with the correct parameters.

That is perfectly OK for me. However two more suggestions:

• Add *args, **kwargs to the signature.
• Pass mi as more friendlier name like book. This way, the user can get metadata with book.title, book.authors, .... etc which is more intuitive than mi.title ....etc. Ofcourse for custom columns it would be book.get('#my_custom_column'). Although, if OK with Kovid, we can make the mi object subcriptable to be able to something like book['#my_custom_column']

Originally Posted by chaley

Hmmm ... I could get rid of "python:", instead using "def evaluate(mi, db):" as the key. I am not sure that would is better. It might have some future compatibilty advantages if we want to use a different argument profile. The formatter could directly determine which argument profile the python template is using. On the other hand, using "python:" could permit us to define multiple evaluator methods. I don't see a use for this, but ???. I lean toward "python:".

Future proofing is always a good idea.