GraphQLError crashes for parsed AST node tuples despite accepting Collection[Node] #321

GraphQLError accepts nodes: Collection[Node] | Node | None, but passing the parser's tuple of AST nodes raises AttributeError. Passing the same nodes as a list works.

Reproduced on current main at 1d505c19bf5fb8da0205165b78af6094d637009e (3.3.2), Python 3.14.9:

from graphql import GraphQLError, parse

nodes = parse("{ first second }").definitions[0].selection_set.selections
print(type(nodes))  # tuple
error = GraphQLError("Problem with these fields", nodes=nodes)
# AttributeError: 'tuple' object has no attribute 'loc'

Expected: the error has both node locations, as it does with nodes=list(nodes):

[
    {"line": 1, "column": 3},
    {"line": 1, "column": 9},
]

The constructor wraps every non-list value as a single node. A tuple therefore becomes [tuple_of_nodes] and fails when locations are read. This also affects other supported collections such as deque.

A small proposed fix keeps the existing list path, converts other Collection values to a list, and continues wrapping a single node. This would let custom validation code attach a parser-produced node collection without an extra list conversion. It does not change GraphQL semantics or the AST's tuple representation.

The private patch adds tuple, deque, empty-tuple and location-free-tuple tests. Three fail before the fix. On the patch, pytest tests passes with 3,826 passed, 18 skipped and 100% source/test coverage on Python 3.14.9. The Python 3.10 suite excluding benchmarks, full Ruff check/format and full mypy also pass. Other platforms and slow tests have not been run.

Would this collection normalization be welcome as a small PR? The change is separate from #320's suppressed-exception-context fix.

AI disclosure: this report, proposed code and tests were generated with an AI assistant.