Alternative to @v_args()

[makukha]

Suggestion

1. Use explicitly named decorators: @wrap_every (class level only), @inline_children (method level only)
2. Let Transformer decide which arguments to pass based on method signature:
   • If method has single argument, pass children regardless of its name (this will preserve backwards compatibility)
   • If args are subset of {meta, tree, children} — pass respective values.
3. v_args is left unchanged for backwards compatibility.

This may make API more explicit and sound. The second approach is used in e.g. Pydantic (see validators in v.1).

I'm not aware of all possible use cases for v_args, but at least some of them are covered.

Describe alternatives you've considered
@v_args is the only alternative.

Additional context
Usage examples:

Class level only @wrap_every

@wrap_every(inline_children)
class Demo(Transformer):
    def rule(self, *items): ...

Method level only @inline_children

class Demo(Transformer):
    def rule1(self, children): ...
    @inline_children
    def rule2(self, *items): ...

Method signature auto detection

class Demo(Transformer):
    def rule1(self, items): ...  # children passed
    def rule2(self, tree): ...  # tree passed
    def rule3(self, meta, children): ...  # pass meta, children
    def rule4(self, meta, items): ...  # to be decided: raise error or pass children to items
    @inline_children
    def rule5(self, tree, meta, *items): ...

If this change sounds reasonable, I'm ready to work on PR.

[erezsh]

Use explicitly named decorators: @wrap_every (class level only), @inline_children (method level only)

Can you explain your rationale?

[makukha]

Use explicitly named decorators: @wrap_every (class level only), @inline_children (method level only)

Can you explain your rationale?

First of all, let me say that Lark is an awesome project and already saved me days of life. I appreciate hard work, dedication and talent of Lark's maintainers. I don't understand much in parsers and lexers, but want to dedicate some of my time to the field where I touch Lark the most as a developer: its API.

The main reasons for change proposed are

1. Separation of features applicable in different contexts.
2. Easier support: every feature can be updated/fixed independently.
3. Readability, better naming, less user code (lower cognitive load).

For v_args(meta=, tree=):

• This syntax can be eliminated, args can be deduced from method signature (methods are not called manually, Lark can do this itself).

For v_args(wrapper=):

• This feature does not make sense when applied to individual method, is applicable only at class level.

For v_args(inline):

• Not immediately obvious what is inlined, inline_children seems better to me. Also this will be more readable when used as a standalone decorator on methods.
• Actually, it can be used at class level too, @inline_children is more readable that @wraps_every(inline_children), if your question was about this case.

[erezsh]

Thanks for the write-up, it sounds like you gave it some thought.

The idea of v_args is as a primitive to allow creating a decorator that suites you.

For example, you could write: inline_children = v_args(inline=True)

You could also create a decorator with v_args(wrapper=...), and apply it to any function you want, or the entire class.

So, I think that the fact that it can apply in different contexts is actually an advantage.

Sorry to say, but I didn't find your proposal convincing.

You mention easier support, but we'll still have to support v_args, to preserve backwards compatibility.

Also, the following change:

If args are subset of {meta, tree, children} — pass respective values.

Would be backwards incompatible, and might break someone's code in a very confusing way.

Keep in mind inline children usually don't use *args, but actually name the children, since the arguments are known from the grammar.

Maybe the API you propose would have been an improvement, if done this way from the start. But I think transitioning to it now would create a lot of confusion, and with very little benefit.

[makukha]

@erezsh appreciate your explanation! Well, I think this syntactic sugar is not SO important even if safe to implement, and this feature request can be closed :)

[erezsh]

Thanks for the suggestion anyway!