View Single Post
Old 10-14-2022, 04:55 AM   #57
un_pogaz
Chalut o/
un_pogaz ought to be getting tired of karma fortunes by now.un_pogaz ought to be getting tired of karma fortunes by now.un_pogaz ought to be getting tired of karma fortunes by now.un_pogaz ought to be getting tired of karma fortunes by now.un_pogaz ought to be getting tired of karma fortunes by now.un_pogaz ought to be getting tired of karma fortunes by now.un_pogaz ought to be getting tired of karma fortunes by now.un_pogaz ought to be getting tired of karma fortunes by now.un_pogaz ought to be getting tired of karma fortunes by now.un_pogaz ought to be getting tired of karma fortunes by now.un_pogaz ought to be getting tired of karma fortunes by now.
 
un_pogaz's Avatar
 
Posts: 447
Karma: 678910
Join Date: Dec 2017
Device: Kobo
Quote:
Originally Posted by chaley View Post
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 View Post
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 View Post
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 View Post
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)

Last edited by un_pogaz; 10-14-2022 at 04:58 AM.
un_pogaz is offline   Reply With Quote