OMetaBase.apply should take kwargs, and _GrammarWrapper should pass them along

[Julian]

Maybe if I create some tickets it will persuade me to actually send you pull requests.

Right now _GrammarWrapper eats kwargs, so you can't actually get anything to the rules without icky positional args.

[washort]

what would the syntax for rules that take keyword args look like?

[Julian]

I don't know! Good question. Maybe this is not such a great idea, and also probably since I don't need it anymore I probably won't think too hard about it, so maybe it should go away. Keyword args are so much cooler than positional args though so maybe this would be a nice thing if it were possible.

[Julian]

ruleName(arg1=foo arg3=bar arg2=baz) is probably the obvious thing

[Julian]

Or I guess ruleName(foo:arg1 bar:arg3) would be somewhat consistenty in a cutesy way.

[washort]

if you can figure out how to make it work I would love to see a patch.
(P.S. First see if you can figure out how positional arguments currently work! :)

[versae]

I don't know if related, but I had a rule in which some parameters could be or could not, by using ?

rule = <("this" | "that"):r>? "one":o "two":t
      -> rule_func(**locals())

So rule_func is defined like

def rule_func(r=None, o=None, t=None, **kwargs):
    return {}  # real code goes here

Is this the proper way to go?

[washort]

No. locals() will not do what you want here, and should never be used in Python code.

[versae]

I know, but actually it does work. So, what is the right way to manage optional variables?

[washort]

well first, the <> brackets are not doing anything in your case since you ignore the value they return and it would be the same as the literal anyway.

I would rewrite the first expression as ("this" | "that")?:r. r will be None if the expression is not matched.

[versae]

I see, thanks for the explanation.