Syntactic sugar for union cases in match statements

[mikeshardmind (Michael H)]

While I would disagree that Unions are ADTs as people are familiar with the term from other languages, I would agree that the problems ADTs help solve are already solvable with things python has.

Unions are a type-system exclusive construct, yes you can do a limited number of things with them at runtime, but that’s not their primary purpose and very little exists around that. This is partially intentional, as having runtime behavior on typing features that isn’t clearly separated has lead to problems of inconsistency like…

@erictraut

When _AnnotatedAlias is called, the behavior depends on the first type argument of Annotated. If the first type argument happens to be an instantiable type form, the constructor is called, and an instance of that type is returned. For example, Annotated[tuple, ""]([1, 2, 3]) returns a tuple object.

However, many type forms are not instantiable. For example, Annotated[int | str, ""]() raises an exception.

If this is an unintended and undocumented behavior, my inclination is to file a cpython bug and suggest that this unintentional behavior be eliminated — perhaps by overriding the _AnnotatedAlias.__call__ method with a method that always raises an exception.

The challenge here is that it appears some developers have started to rely on this undocumented behavior , so it may be difficult to put the genie back in the bottle at this point.

and

@tmk

Other justification: unions already work with isinstance:

Even isinstance’s second parameter accepting a Union has been considered a mistake by a few people in hindsight. This recently came up in another discussion with adding isinstance support to other type-sytem parts (quoted below).

@Jelle

I touched on this a bit in my earlier messages in the thread. The type statement adds two unique capabilities: lazy evaluation and the use of unambiguously scoped type variables. Both of those capabilities don’t play well with use in isinstance().

I don’t particularly like the fact that isinstance() works with unions, but removing that behavior would be a compatibility break and I don’t see a strong case for doing so.

After some consideration, I’m negative on adding match support to Union but positive on an ADT construct that works with or without the type system and Unions (though it should be compatible for typing users, it should work for non-typing uses given the motivations)