Quote:
Originally Posted by chaley
Why use object.__setattr__() in FormatterFuncsCaller __init__ instead of
Code:
self.formatter = formatter
|
In a first implementation, I removed/invalidated __setattr__ from FormatterFuncsCaller.
Quote:
Originally Posted by chaley
What is the point of the recursive get_attribute() in FormatterFuncsCaller (line 892)? As far as I can see an instance of FormatterFuncsCaller doesn't have any attributes other than .formatter.
|
__dir__, __dict__ and other internal special function.
As I write this reply I am beginning to see your point and I have an idea, I will see.
Quote:
Originally Posted by chaley
What about not requiring the trailing '_' if there is no collision with a python keyword? FormatterFuncsCaller.__get_attribute__() could check the name with and without the underscore.
|
Now that you mention it, Yep. The ability to call with '_' at the end will remain for all functions as a backup. Hum, I'll have to think about a solution to make the call priority right, even if putting '_' at the end of its template/function is unusual.
Quote:
Originally Posted by chaley
Do we want the 'hidden' attributes .formatter and .funcs in PythonTemplateContext.attrs_set? I think these aren't something the user should use or see. No need for them to be in the output of __str__().
|
Hidden .formatter, Yes, there is no need to know that it is there. Just don't forget to write it in the manual as an indication (basically, we don't need it, but know current formatter is very "contextual").
.funcs less sure. I plan to write a doc about it once the feature is stable.
Quote:
Originally Posted by chaley
This error exception should be simpler:
EXCEPTION: Error in function evaluate on line 4 : AttributeError - 'FormatterFuncsCaller' object has no attribute 'a_python_template'
Perhaps something like this:
EXCEPTION: Error in function evaluate on line 4 : AttributeError - no function 'a_python_template' exists
|
Noted
Quote:
Originally Posted by chaley
I am a little concerned about recursion in processing templates, but that can happen today. Oh well.
|
Oh, yes, sure .funcs is a good way to blow up the stack
But like in any other program. If you're in python mode, it's either a notion you know, or you learn it very quickly
. The main goal is the buildin and user function, therefore, little risk.
And then, a reccursive call, it is rarely done by "accidents".
EDIT: And a found a way to clean the list of native attribute. Now, all is inside __get_attribute__.
A also fix globals(), arguments() (which returns dict) and set_globals(), character().
Push on my github