View Single Post
Old 10-08-2022, 07:32 AM   #9
capink
Wizard
capink ought to be getting tired of karma fortunes by now.capink ought to be getting tired of karma fortunes by now.capink ought to be getting tired of karma fortunes by now.capink ought to be getting tired of karma fortunes by now.capink ought to be getting tired of karma fortunes by now.capink ought to be getting tired of karma fortunes by now.capink ought to be getting tired of karma fortunes by now.capink ought to be getting tired of karma fortunes by now.capink ought to be getting tired of karma fortunes by now.capink ought to be getting tired of karma fortunes by now.capink ought to be getting tired of karma fortunes by now.
 
Posts: 1,203
Karma: 1995558
Join Date: Aug 2015
Device: Kindle
Quote:
Originally Posted by chaley View Post
Another good point. I hadn't considered using a mechanism like python formatter functions, but created dynamically instead of statically. The code mostly exists to handle this. The dynamic function could have the same argument list as a stored python function, or perhaps a simpler one like
Code:
evaluate(mi, db)
where db might be None. The simpler form wouldn't be usable in the EvalFormatter, used when rendering author links, identifier link rules, and tag browser collapse model templates. It also couldn't use the standard template processor, for example to use formatter functions. Like a stored python template, a synamic python template must return a string.
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.

Quote:
Originally Posted by chaley View Post
I would create a class instance for it. The class instances would be cached, so you could store 'stuff' as instance variables and they would persist during the cache lifetime. Templates that are cached: icon and color rules, emblems, composites, and template searches. The caches are cleared whenever something changes the database, or in the template search case on every new search.
+1. I even use the instances of the current formatter functions to persist things.

Quote:
Originally Posted by chaley View Post
This method avoids creating a new function syntax, which makes things easier both to implement and to document. It loses being able to intermix chaley-language templates and python-language templates, but that is probably a small loss.
That is where feedback from others would help. I see un_pogaz has already chimed in.

Quote:
Originally Posted by chaley View Post
I would need to make the template editor handle these, probably by removing all syntactic highlighting in "python:" mode.
Yes. I also don't see a need to ever re-implement syntax highlighting for python in the template editor. People can simply use their favorite editor/IDE for that, and copy paste into the template editor.

Quote:
Originally Posted by chaley View Post
Finally, this method removes the need for dict_... methods. If you know what a dict is and how to use them then you probably can write in python, or at least understand examples well enough to change them.
I would say so. Plus all the other features that comes for free with python.

Quote:
Originally Posted by un_pogaz View Post
Wow, that could be very powerful indeed. But it would be necessary to define its "main function" as well as its arguments, a bit like it is the case for template functions. This would allow to create "template function for single use".
Code:
python:
def main(mi):
    ...
    your python code
    ...
Note that since python accepts local definitions, we can all write in main()
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. Edit: The call to the function is done automatically as well.

Last edited by capink; 10-08-2022 at 08:06 AM.
capink is offline   Reply With Quote