(moving to list)
> In Python, if you used named parameters, I think it can be more like JS and
> PHP. But
> that might be a Python 3.x thing. I can't remember where I read that....
Named parameters let you *omit* parameters, but you can't add extra ones.
> If there is to be a break for the other languages, it could be with four
> parameters:
>
> formatter_function (data, context, formatter, argument_string)
OK, I think I thought of a solution. I agree it is a little obscure
to write say the Plural and PythonPercent in formatters.py. Multiple
people have brought this up, and I guess it is mathematically nice but
doesn't really match the way people think about the problem.
And also we now have use cases for 2 more arguments -- context and arg
string (I don't see why you need the original name).
So I propose something like this:
class FunctionRegistry(object):
def RegisterFunction(name, func, args, uses_context=False):
pass
def Lookup(self, user_str):
"""
user_str: String that comes directly from the tepmlate
"""
returns a function, and what args it should be called with
And you can chain FunctionRegistries in a list. I also want global functions:
jsontemplate.SetFormatters(registry)
jsontemplate.SetPredicates(registry) # These are used for all templates
BUT -- there is one complication in that looking up the function name
and parsing the arguments can happen at compile time. Substituting
the value can only happen at runtime.
So in that sense the current behavior is actually correct. It could
be made more intuitive by writing formatters like this:
class Formatter(object):
def __init__(self, args):
self.args = args # Args are known at compile time, and should be
checked for validity at compile time
def __call__(self, value, context):
# value and context are only known at runtime
I'll have to think about it a little more. Maybe it's OK to just
ignore this -- save the args somewhere, and then just apply them at
runtime.
> You could conceivably have the call type (one param or four params) to
> formatters and
> predicates be based on option, like meta characters are. In such a case,
> the user
> would have to specifically ask for feature that might then break their code,
> otherwise everything degrades to the current system.
So, the option should be per-formatter, not per-template. You don't
want set an option for the entire template. In my example that's done
with args to the RegisterFunction method.
Andy
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JSON
Template" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/json-template?hl=en
-~----------~----~----~----~------~----~------~--~---
