Quote:
Originally Posted by capink
If the simpler form is not able to do all of the above, it leaves it with only one tiny advantage; the ability to add more arguments to the function definition in the future if a need for this arises.
|
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.
Quote:
|
The idea is that the code will be wrapped into the function definition — by simply replacing python: with the def whatever() — This way we are not tied to a pre-defined signature.
|
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:
Code:
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.
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:".