This PR is part of a response to the Sequences section of this blog post, see there for context. Related issue
Introduce an alternative to parsy's seq parser, with type annotations. This approach combines parser results into a tuple without increasing the nesting level for each extra parser in the sequence. Once a sequence is created, the result tuple can be passed to a function as *args using the previous .combine syntax.
The benefit is that Pyright will check that the result type of each parser in the sequence against the argument types of the combined function. Without needing extra steps like un-nesting tuples from the result.
For example, in the screenshot below, the demo function expects its first argument to have a type of str. A parser of type Parser[int, str, bool] can be made with the join and append functions. Then where combine is called, VSCode shows that there's a problem - the parser result type doesn't match demo's parameter type in the first argument.
This PR is part of a response to the
Sequencessection of this blog post, see there for context. Related issueIntroduce an alternative to
parsy'sseqparser, with type annotations. This approach combines parser results into a tuple without increasing the nesting level for each extra parser in the sequence. Once a sequence is created, the result tuple can be passed to a function as *args using the previous.combinesyntax.The benefit is that Pyright will check that the result type of each parser in the sequence against the argument types of the combined function. Without needing extra steps like un-nesting tuples from the result.
For example, in the screenshot below, the demo function expects its first argument to have a type of str. A parser of type Parser[int, str, bool] can be made with the join and append functions. Then where combine is called, VSCode shows that there's a problem - the parser result type doesn't match demo's parameter type in the first argument.