Skip to content

Python parsing of subscripts that unpack a string or parenthesised expression produces ERROR nodes #367

Closed

Description

@pjljvandelaar

Observed. test/python/ast/test_python_lst_node.py::TestPythonLstNode::test_from_cst_returns_statement failed in CI on PR #318 (run 40916710765), with the Hypothesis input for 0J[*''] in ...: pass. The first child of the created node has SemanticKind.NODE instead of loop.

Cause. tree-sitter-python 0.25.0 does not parse a starred expression in a subscript (PEP 646, Python 3.11+) when the operand is a string or a parenthesised expression:

Code First child
for x[*y] in z: pass loop
for x[*y.z] in z: pass loop
for x[*''] in z: pass node
for x[*'a'] in z: pass node
for x[*(y)] in z: pass node
x[*'a'] node

The parse is (module (ERROR (identifier) (slice (list_splat (ERROR (string (string_start) (string_end))) (identifier)))) (pass_statement)). CPython 3.14 accepts the code: ast.parse gives Subscript(value=Constant(0j), slice=Tuple([Starred(Constant(''))]), ctx=Store()).

Reproduce. PythonFactory(LSTNode).create_from_text("x[*'a']\n").children[0].semantic_kind, or add @reproduce_failure('6.169.4', b'AEEBQQEAQQNBDkEAgTAAgUoBQQBBBIBBAkEAQQAAQQk=') to the test.

Not a regression. The PR changes no parser code and no parser or Hypothesis dependency. The test draws random examples, and this input is rare.

Options. Report it upstream to tree-sitter-python; until then, record the case as an explicit xfail example, or have the test skip inputs that tree-sitter cannot parse.

Activity

  1. added a commit that references this issue on Nov 4, 2026
  2. FrancescoPezzella commented on Nov 4, 2026

    @FrancescoPezzella
    Collaborator

    also relevant, tree sitter does not support default or lazy keywords - its last update was over a year ago, the repo is not being maintained

  3. pjljvandelaar commented on Nov 4, 2026

    @pjljvandelaar
    CollaboratorAuthor

    Closed by pull request #368

  4. FrancescoPezzella commented on Nov 4, 2026

    @FrancescoPezzella
    Collaborator

    4. Closed by pull request #368

    FYI If you add "Fixes #368" in the description of the PR, then GitHub will automatically close the issue upon the PR being merged :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions