Quote:
Originally Posted by chaley
You are adding the ability to call builtin formatter functions from python templates. Calling these functions requires you to accept that the functions return strings, even when that doesn't make sense given the underlying data.
|
It's a pity but it's "normal" because you use the function as Calibre calls it itself. It's a point to underline in their doc and usage.
Quote:
Originally Posted by chaley
For example, by looking at the source for formats_sizes() and human_readable() (easily available), assuming I know python I see how to call the underlying db methods. Using that knowledge I can write your template as
Code:
python:
from calibre import human_readable
def evaluate(book, context):
return ','.join([k+ ':' + human_readable(v['size'])
for k,v in book.get('format_metadata', {}).items()])
which avoids the conversion to/from strings while building the base data.
The same function could be written in TPM as
Code:
program:
sizes = formats_sizes();
result = '';
for fmt in sizes:
list_split(fmt, ':', 'v');
result = list_join(',', result, ',', v_0 & ':' & human_readable(v_1), ',')
rof;
result
|
Yes, of course you could do better if you decided to import the code if you wanted to. My example is simple, but it is a basis for discussion. Other buildin functions can be more cumbersome to import.
The main goal is to have a "zero brain" import of the buildin function. It's not the "best" (I agree) but it's better than
not having them at all.
Quote:
Originally Posted by chaley
Another issue, probably not important: the arguments(), globals(), and set_globals() functions are implemented directly in the formatter. A user cannot call the functions in .funcs.
|
Oh, I'll look into it.
Quote:
Originally Posted by chaley
Does the gain justify the ongoing maintenance cost?
|
The gain is very low, I agree again, but the maintenance cost too because the attributes are automatically created by the initialization of the class on the basis of the functions inside the formatter you used to initialize it (even better, I have push a version that uses __getattribute__, so it is dynamic at the change in formatter.funcs)
Only some special functions (like the one you told me) need to be treated. It's a bet that there won't be another one in the future, but it doesn't represent a big problem (I work well good of the one you pointed out)