[chaley]

Originally Posted by capink

That is perfectly OK for me. However two more suggestions:[*]Add *args, **kwargs to the signature.

Why? There is no way a user can pass extra arguments. Having these implies it is possible, which could lead to confusion and bug reports.

I think what you are looking for is future proofing and simplifying git forking. How about we make the protoype be

def evaluate(**arguments): # This could be **kwargs if that is better for some reason

The template processor would call the method using only keyword arguments, for example:

evaluate(book=book, db=db)

The evaluate() method would do something like

book = arguments['book']
db = arguments['db']

For me this is more clear than args[0] etc.

In the future, more named arguments could be added without breaking existing python templates.

Originally Posted by capink

[*]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.

That makes sense. It is named 'book' when passed to safe_format().

Originally Posted by capink

Of course 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']

I am not in favor of making mi subscriptable. Reasons:

• It could imply that the book object is really a dict, which it isn't.
• It requires every place that mi is built to implement subscripting. I know of at least 4 places: proxy_metadata, metadata.books, OPF processing, and save_to_disk. I am 90% sure there are more.
• Adding subscripting is a significant change that could break things. Is the risk worth it?
• The construction dict.get('key') is basic to python. It shouldn't be a surprise to the user.
• book.get('title') works, so the user doesn't need to worry about two access methods.

Originally Posted by capink

Also, we can still be tied with a signature, but not make the user type it every time, and go with python: alone without needing the def line.

This is possible but it makes indenting problematic. All defs must be at the outermost indent, while the code must be further indented. Helper functions must be indented at the same level as "def evaluate()".

Adding on to the above suggestion about **arguments, how about adding a line to the context menu of the template editor that inserts

python:
def evaluate(**arguments):
    book = arguments['book']
    db = arguments['db']

This is both a shortcut for typing and aids discoverability.