Abstract:
The current implementation of Python’s structural pattern matching does not support direct matching against set literals, limiting concise and expressive pattern matching with sets. This proposal suggests enhancing pattern matching to natively support set literals, including patterns that capture elements, while acknowledging the inherent limitations of working with unordered collections like sets.
Background:
Structural pattern matching, introduced in Python 3.10, allows for expressive and readable code when dealing with complex data structures. However, it currently does not accommodate direct matching with set literals or patterns that capture elements within sets. Sets are unordered collections, which introduces specific constraints on how pattern matching could work with them.
Problem Statement:
Attempting to use pattern matching with set literals and capture patterns results in a SyntaxError. For example:
example = {1, 2, 3, 4}
match example:
case {1}: # SyntaxError
print("Contains only 1")
case {1, other}:
print(f"Contains 1 and another element: {other}")
case {1, 2, *other}:
print(f"Contains 1, 2, and other elements: {other}")
case _:
print("Other set")
This code raises a SyntaxError.
Given that sets do not maintain any specific order, certain pattern matching syntaxes that work with ordered collections (such as lists or tuples) cannot be directly applied to sets. Specifically:
- Positional matching with multiple placeholders (e.g., case
{a, 2, 3, b}or{a, 2, 3, *b}) is not valid for sets because there is no defined order in sets. In this case, it is unclear what element should be assigned to the positional variable a and what should be placed into the catch-all variable *b. This ambiguity arises due to the unordered nature of sets. - Type checking can still be used in patterns, like case
{int(a), 2, 3}:, but this is limited to patterns where there is only one “catch-any” variable (i.e., no use of multiple*args-likesyntax in set matching). - The catch-all pattern (
*other) in set literals can only be used alone and once, as there is no guarantee of order in sets, and sets cannot be “unpacked” in the same way as ordered collections like lists or tuples.
Proposal:
Extend the pattern matching syntax to support set literals and capture patterns, enabling expressions such as:
match example:
case {1}:
# Handle case where example is {1}
case {1, other}:
# Handle case where example contains 1 and another element
case {1, 2, *rest}:
# Handle case where example contains 1, 2, and other elements
case _:
# Handle all other cases
However, the following limitations should be clearly noted:
- Positional pattern matching for multiple placeholders (e.g.,
{a, b, c}) is not valid for sets. The unordered nature of sets means there is no guarantee of the positions of elements. Therefore, it is unclear where to place each element in the pattern, making positional matching impossible. - Pattern “catch-all” (
*other) can be used only once and without other patterns, as there is no defined order of elements in sets. This limitation ensures there is no ambiguity about how the elements are matched. - Type checking can be applied, e.g., case
{int(a), 2, 3}:, but without the full flexibility that ordered collections (like lists or tuples) offer. Open for discussion.
Benefits:
- Conciseness: Eliminates the need to convert sets to other data types for pattern matching.
- Readability: Provides clear and direct expressions of intent when working with sets.
- Consistency: Aligns pattern matching capabilities across different collection types, even if sets introduce some specific limitations due to their unordered nature.
Reference:
Discussion:
Implementing this feature requires careful consideration of backward compatibility and potential parsing ambiguities. Since sets do not guarantee order, it is important to ensure that the semantics of pattern matching align with the characteristics of sets.
Conclusion:
Enhancing Python’s pattern matching to support set literals and capture patterns will improve the language’s expressiveness and consistency, benefiting developers working with set data structures, while acknowledging the limitations due to the unordered nature of sets.