Pylint errors on Pyparsing v3.1.0 with old-style method/argument names

[Riccardo Coccioli]

Summary

I've some existing code that with pyparsing 3.0.9 or previous passes pylint just fine while it fails on pyparsing 3.1.0.
I'm using the old method and argument names because my code is compatible with Pyparsing 2.x, so changing the calls to the new ones is not an option for me.

Versions

• Python 3.11.3

$ pip freeze | grep py
pylint==2.17.5
pyparsing==3.1.0

Repro code

Save this into repro.py:

"""My module."""
import pyparsing


def repro(string: str):
    """Do something."""
    grammar = pyparsing.NoMatch()
    return grammar.parseString(string, parseAll=True)

Repro steps

With a venv with the latest pylint and pyparsing 3.1.0 run:

$ pylint repro.py
************* Module repro
repro.py:8:11: E1121: Too many positional arguments for method call (too-many-function-args)
repro.py:8:11: E1123: Unexpected keyword argument 'parseAll' in method call (unexpected-keyword-arg)

------------------------------------------------------------------
Your code has been rated at 0.00/10 (previous run: 0.00/10, +0.00)

To clarify this is not the only error reported by pylint, I have various others, all involving old-style method/arguments names.

Changing the last line in repro.py to the new syntax: return grammar.parse_string(string, parse_all=True) makes pylint happy.
My guess is that the compatibility code is the one responsible for this issue, maybe pylints reads it from https://github.com/pyparsing/pyparsing/blob/master/pyparsing/core.py#L2287 ?

[Paul McGuire]

Yes, it looks like the compatibility function is the issue here, even though the replication decorator does use the __annotations__ dunder attribute to try to replicate method signatures from the new syntax methods to the legacy ones.

[Paul McGuire]

If you want to put together a PR that updates the legacy method signatures, I would be happy to review and apply it.

[Riccardo Coccioli]

@ptmcg I've sent a proposal PR with a slightly different approach.
Instead of duplicating all the signatures for all the methods, risking that they will drift between the two names, I opted for calling directly the _make_synonym_function function.
Let me know what do you think and also if you'd like to rename the _make_synonym_function to something else.