Yes, this would need to be a new PEP. I'd probably be willing to sponsor such a PEP.

Thanks Jelle. I will try to put a PEP together, likely pulling heavily from the section already written in PEP 622.

El sáb, 16 abr 2022 a las 13:47, John Hagen (<johnthagen@gmail.com>) escribió:

...

Yes, this would need to be a new PEP. I'd probably be willing to sponsor such a PEP.

Thanks Jelle. I will try to put a PEP together, likely pulling heavily from the section already written in PEP 622.

Looking at that section again, I noticed a problem with the spec at https://peps.python.org/pep-0622/#sealed-classes-as-algebraic-data-types. Given a class hierarchy with `Node` as the base class and a number of leaf classes, it says "With such definition, a type checker can safely treat Node as Union[Name, Operation, Assignment, Print]". But there is nothing in the code sample that tells a type checker that an object of type `Node` can't be an instance of the base class. Presumably you could use `abc.ABCMeta` to indicate that the base class is abstract, but that may be disruptive at runtime, because it requires using a metaclass. Eric's feedback is also important to consider. What compelling benefit does this new type system feature provide over just using a Union?

_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com

On Sun, Apr 17, 2022 at 12:46 PM Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:

El sáb, 16 abr 2022 a las 13:47, John Hagen (<johnthagen@gmail.com>) escribió:

...

...

Yes, this would need to be a new PEP. I'd probably be willing to sponsor such a PEP.

Thanks Jelle. I will try to put a PEP together, likely pulling heavily from the section already written in PEP 622.

Looking at that section again, I noticed a problem with the spec at https://peps.python.org/pep-0622/#sealed-classes-as-algebraic-data-types. Given a class hierarchy with `Node` as the base class and a number of leaf classes, it says "With such definition, a type checker can safely treat Node as Union[Name, Operation, Assignment, Print]". But there is nothing in the code sample that tells a type checker that an object of type `Node` can't be an instance of the base class. Presumably you could use `abc.ABCMeta` to indicate that the base class is abstract, but that may be disruptive at runtime, because it requires using a metaclass.

Type checkers could probably just treat the base class of a sealed class as implicitly abstract. (Just as they would treat every subclass as `@final` outside the module.)

Eric's feedback is also important to consider. What compelling benefit does this new type system feature provide over just using a Union?

Perhaps nothing other than the convenience of not having to repeat the class names in the definition of the union (at the cost of having to define the base class, adorn it with `@sealed`, and repeating that as the base class for all the case classes). I also agree with Eric that it feels awkward to require that all the case classes must be defined in the same file -- this violates a general refactoring principle. Though maybe it's okay (just like all methods of a class must be defined in the same file). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

On Mon, Apr 18, 2022, at 14:24, John Hagen wrote:

One of the benefits that the base-class approach has over the Union approach is that the base type can define additional state and methods that the variants can implement, or can be used when referring to the base type. I see this as being more a more general and flexible ADT.

You can achieve this without `@sealed` by changing Coin -> BaseCoin, and adding `Coin = Nickle | Dime | Quarter`. `@sealed` helps avoid the need for the `Coin`/`BaseCoin` separation, and for repeating the sub-class names, but it is not essential. Ran

You can achieve this without `@sealed` by changing Coin -> BaseCoin, and adding `Coin = Nickle | Dime | Quarter`.

There are some edge cases to this approach. For example, you can't put Coin in another Union and match on it because Unions do not implement isinstance: Coin = Nickle | Dime | Quarter def get_value(coin: int | Coin) -> int: match coin: case int(): return coin case Coin(): # TypeError: called match pattern must be a type return coin.value get_value(Dime())

If all of the classes in the union derive from the same base class, you can use the base class for the `isinstance` check or case statement.

You're not wrong, but I would consider it quite annoying to have to import both Coin and BaseCoin in order to use this ADT. Conceptually, they are the same thing split into two. If this became standard, I think Python would be the first programming language in which the base class of an ADT and the type of the ADT were distinct names and objects.

Beyond the annoyance of multiple imports, there's also the potential issue of non-Union subclasses of BaseCoin. I've used this pattern a few times, and it works alright, but it feels inelegant to have 2 types that conceptually represent the same point in the type hierarchy, and can create confusing when trying to use one in an invalid way. It also creates an opportunity for those points to, unintentionally diverge. That being said, I'm not a huge fan of the `sealed` decorator suggestion. It seems like it would be easy to miss when refractoring or adding classes. I think I'd prefer something like: ``` class Tree(Sealed[Node, Leaf]): ... class Node(Tree): ... class Leaf(Tree):. ``` To keep the anticipated sub classes specific, and work more similarly to `abc.ABC` Or, if something more implicit through location is desired, to avoid repetition, then at least a shared indentation would be clearer: ``` with sealed('Tree'): class Tree: ... class Node(Tree): ... class Leaf(Tree):... ``` (Just to illustrate the idea, I'm sure there's a better representation) But I'm not convinced the relatively limited repetition is sufficiently compelling. On Tue, 19 Apr 2022, 01:17 David Hagen, <david@drhagen.com> wrote:

...

If all of the classes in the union derive from the same base class, you can use the base class for the `isinstance` check or case statement.

You're not wrong, but I would consider it quite annoying to have to import both Coin and BaseCoin in order to use this ADT. Conceptually, they are the same thing split into two. If this became standard, I think Python would be the first programming language in which the base class of an ADT and the type of the ADT were distinct names and objects. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: diabolo.dan@gmail.com

I think I'd prefer something like: ``` class Tree(Sealed[Node, Leaf]): ... class Node(Tree): ... class Leaf(Tree):. ```

Some languages do make you explicitly list out of the subclasses (e.g. Java and Ceylon) rather than requiring that all the subclasses simply be defined in the same file (e.g. Kotlin and Scala). I sympathize with both designs. The same-file sealed directive avoids having to repeat the names of the subclasses, while the explicit list avoids having the weird requirement that all the subclasses be in the same file. In a statically typed language, I think I would lean toward the explicit list, but in Python, this is very problematic. The explicit list is inherently a circular reference, which is fine in a statically typed language, but in Python there is just no place to put the explicit list where the runtime can pass over it. In your example, the interpreter would fail at Sealed[Node, Leaf] because name Node is not defined. Now that I think about it, maybe you could do some weird stuff with lazy annotations. There is no natural place to put the annotation, but there is no limit to the number of unnatural places. ``` form __future__ import annotations class Tree: ... __sealed__: Node | Leaf class Node(Tree): ... class Leaf(Tree): ... ```

David and I are pleased to share a draft PEP. We welcome any additional feedback. It can be viewed rendered at: https://github.com/johnthagen/sealed-typing-pep PEP: <REQUIRED: pep number> Title: Adding a sealed qualifier to typing Author: John Hagen <johnthagen@gmail.com>, David Hagen <david@drhagen.com> Sponsor: Jelle Zijlstra PEP-Delegate: <PEP delegate's real name> Discussions-To: typing-sig@python.org Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17-Apr-2022 Python-Version: 3.12 Post-History: Resolution: <url> Abstract ======== This PEP proposes a ``@sealed`` decorator be added to the ``typing`` module to support creating versatile algebraic data types (ADTs) which type checkers can exhaustively pattern match against. Motivation ========== Quite often it is desirable to apply exhaustiveness to a set of classes without defining ad-hoc union types, which is itself fragile if a class is missing in the union definition. A design pattern where a group of record-like classes is combined into a union is popular in other languages that support pattern matching [1]_ and is known as a nominal sum type, a key instatiation of algebraic data types [2]_. We propose adding a special decorator class ``@sealed`` to the ``typing`` module [3]_, that will have no effect at runtime, but will indicate to static type checkers that all direct subclasses of this class should be defined in the same module as the base class. The idea is that, since all subclasses are known, the type checker can treat the sealed base class as a union of all its subclasses. Together with dataclasses this allows a clean and safe support of algebraic data types in Python. Consider this example, .. code-block:: python from dataclasses import dataclass from typing import sealed @sealed class Node: ... @sealed class Expression(Node): ... @sealed class Statement(Node): ... @dataclass class Name(Expression): name: str @dataclass class Operation(Expression): left: Expression op: str right: Expression @dataclass class Assignment(Statement): target: str value: Expression @dataclass class Print(Statement): value: Expression With such a definition, a type checker can safely treat ``Node`` as ``Union[Expression, Statement]``, and also safely treat ``Expression`` as ``Union[Name, Operation]`` and ``Statement`` as ``Union[Assignment, Print]``. With these declarations, a type checking error will occur in the below snippet, because ``Name`` is not handled (and the type checker can give a useful error message). .. code-block:: python def dump(node: Node) -> str: match node: case Assignment(target, value): return f"{target} = {dump(value)}" case Print(value): return f"print({dump(value)})" case Operation(left, op, right): return f"({dump(left)} {op} {dump(right)})" Note: This section was largely derived from PEP 622 [4]_. Rationale ========= Kotlin [5]_, Scala 2 [6]_, and Java 17 [7]_ all support a ``sealed`` keyword that is used to declare algebraic data types. By using the same terminology, the ``@sealed`` decorator will be familiar to developers familiar with those languages. Specification ============= The ``typing.sealed`` decorator can be applied to the declaration of any class. This decoration indicates to type checkers that all immediate subclasses of the decorated class are defined in the current file. The exhaustiveness checking features of type checkers should assume that there are no subclasses outside the current file, treating the decorated class as a ``Union`` of all its same-file subclasses. Type checkers should raise an error if a sealed class is inherited in a file different from where the sealed class is declared. A sealed class is automatically declared to be abstract. Whatever actions a type checker normally takes with abstract classes should be taken with sealed classes as well. What exactly these behaviors are (e.g. disallowing instantiation) is outside the scope of this PEP. Similar to the ``typing.final`` decorator [8]_, the only runtime behavior of this decorator is to set the ``__sealed__`` attribute of class to ``True`` so that the sealed property of the class can be introspected. There is no runtime enforcement of sealed class inheritance. Reference Implementation ======================== [Link to any existing implementation and details about its state, e.g. proof-of-concept.] Rejected Ideas ============== Generalize ``Enum`` ------------------- Rust [9]_, Scala 3 [10]_, and Swift [11]_ support algebraic data types using a generalized ``enum`` mechanism. .. code-block:: rust enum Message { Quit, Move { x: i32, y: i32 }, Write(String), ChangeColor(i32, i32, i32), } One could imagine a generalization of the Python ``Enum`` [12]_ to support variants of different shapes. But given that the Python ``Enum`` is more or less a normal class, with some magic internals, this would be a much more invasive change. .. code-block:: python from dataclasses import dataclass from enum import Enum class Message(Enum): @dataclass class Quit: ... @dataclass class Move: x: int y: int @dataclass class Write: message: str @dataclass class ChangeColor: r: int g: int b: int Explicitly list subclasses -------------------------- Java requires that subclasses be explicitly listed with the base class. .. code-block:: java public sealed interface Node permits Leaf, Branch {} public final class Leaf {} public final class Branch {} The advantage of this requirement is that subclasses can be defined anywhere, not just in the same file, eliminating the somewhat weird file dependence of this feature. Once disadvantage is that requires that all subclasses to be written twice: once when defined and once in the enumerated list on the base class. There is also an inherent circular reference when explicitly enumerating the subclasses. The subclass refers to the base class in order to inherit from it, and the base class refers to the subclasses in order to enumerate them. In statically typed languages, these kinds of circular references in the types can be managed, but in Python, it is much harder. For example, this ``Sealed`` base class that behaves like ``Generic``: .. code-block:: python from typing import Sealed class Node(Sealed[Leaf, Branch]): ... class Leaf(Node): ... class Branch(Node): ... This cannot work because ``Leaf`` must be defined before ``Node`` and ``Node`` must be defined before ``Leaf``. This is a not an annotation, so lazy annotations cannot save it. Perhaps, the subclasses in the enumerated list could be strings, but that severely hurts the ergonomics of this feature. If the enumerated list was in an annotation, it could be made to work, but there is no natural place for the annotation to live. Here is one possibility: .. code-block:: python class Node: __sealed__: Leaf | Branch class Leaf(Node): ... class Branch(Node): ... ``Union`` of independent variants --------------------------------- Some of the behavior of ``sealed`` can be emulated with ``Union`` today. .. code-block:: python class Leaf: ... class Branch: ... Node = Leaf | Branch The main problem with this is that the ADT loses all the features of inheritance, which is rather featureful in Python, to put it mildly. There can be no abstract methods, private methods to be reused by the subclasses, public methods to be exposed on all subclasses, ``__init_subclass__``, etc. Even if a specific method is implemented on each subclass, then rename, jump-to-definition, find-usage, and other IDE features are difficult to make work reliably. Adding a base class in addition to the union type alleviates some of these issues: .. code-block:: python class BaseNode: ... class Leaf(BaseNode): ... class Branch(BaseNode): ... Node = Leaf | Branch Despite being possible today, this is quite unergonomic. The base class and the union type are conceptually the same thing, but have to be defined as two separate objects. If this became standard, it seems Python would be first language to separate the definition of an ADT into two different objects. The base class is not merely passive, either. There are a number of operations that will only work when using the base class instead of the union type. For example, matching only works on the base class, not the union type: .. code-block:: python maybe_node: Node | None = ... # must be Node to enforce exhaustiveness match maybe_node: case Node(): # TypeError: called match pattern must be a type ... case None: ... match maybe_node: case BaseNode(): # no error ... case None: ... Having to remember whether to use the base class or the union type in each situation is particularly unfriendly to the user of a sealed class. Footnotes ========= .. [1] https://en.wikipedia.org/wiki/Pattern_matching .. [2] https://en.wikipedia.org/wiki/Algebraic_data_type .. [3] https://docs.python.org/3/library/typing.html .. [4] https://peps.python.org/pep-0622/#sealed-classes-as-algebraic-data-types .. [5] https://kotlinlang.org/docs/sealed-classes.html .. [6] https://docs.scala-lang.org/tour/pattern-matching.html .. [7] https://openjdk.java.net/jeps/409 .. [8] https://peps.python.org/pep-0591/ .. [9] https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html .. [10] https://docs.scala-lang.org/scala3/reference/enums/adts.html .. [11] https://docs.swift.org/swift-book/LanguageGuide/Enumerations.html .. [12] https://docs.python.org/3/library/enum.html Copyright ========= This document is placed in the public domain.

Just like Eric, appreciate the work that has gone into this. I am excited by the idea of ADTs since they are a key part of making invalid state unrepresentable, which is amazing for software correctness. However, I would be disappointed if this version of ADTs was accepted since I think basing our ADTs on the Pythonized version of the Rust syntax would be more usable and elegant. The argument given against it is that this would be a more invasive change, which may not matter for us to get it right the first time? Rust-style enums containing both classes and values would be my ideal scenario. I'm very happy to share actual examples from work where I've wished I had robust ADTs if that would help. On Sat, May 7, 2022 at 7:24 PM John Hagen <johnthagen@gmail.com> wrote:

David and I are pleased to share a draft PEP. We welcome any additional feedback.

It can be viewed rendered at: https://github.com/johnthagen/sealed-typing-pep

PEP: <REQUIRED: pep number> Title: Adding a sealed qualifier to typing Author: John Hagen <johnthagen@gmail.com>, David Hagen <david@drhagen.com> Sponsor: Jelle Zijlstra PEP-Delegate: <PEP delegate's real name> Discussions-To: typing-sig@python.org Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17-Apr-2022 Python-Version: 3.12 Post-History: Resolution: <url>

Abstract ========

This PEP proposes a ``@sealed`` decorator be added to the ``typing`` module to support creating versatile algebraic data types (ADTs) which type checkers can exhaustively pattern match against.

Motivation ==========

Quite often it is desirable to apply exhaustiveness to a set of classes without defining ad-hoc union types, which is itself fragile if a class is missing in the union definition. A design pattern where a group of record-like classes is combined into a union is popular in other languages that support pattern matching [1]_ and is known as a nominal sum type, a key instatiation of algebraic data types [2]_.

We propose adding a special decorator class ``@sealed`` to the ``typing`` module [3]_, that will have no effect at runtime, but will indicate to static type checkers that all direct subclasses of this class should be defined in the same module as the base class.

The idea is that, since all subclasses are known, the type checker can treat the sealed base class as a union of all its subclasses. Together with dataclasses this allows a clean and safe support of algebraic data types in Python. Consider this example,

.. code-block:: python

from dataclasses import dataclass from typing import sealed

@sealed class Node: ...

@sealed class Expression(Node): ...

@sealed class Statement(Node): ...

@dataclass class Name(Expression): name: str

@dataclass class Operation(Expression): left: Expression op: str right: Expression

@dataclass class Assignment(Statement): target: str value: Expression

@dataclass class Print(Statement): value: Expression

With such a definition, a type checker can safely treat ``Node`` as ``Union[Expression, Statement]``, and also safely treat ``Expression`` as ``Union[Name, Operation]`` and ``Statement`` as ``Union[Assignment, Print]``. With these declarations, a type checking error will occur in the below snippet, because ``Name`` is not handled (and the type checker can give a useful error message).

.. code-block:: python

def dump(node: Node) -> str: match node: case Assignment(target, value): return f"{target} = {dump(value)}" case Print(value): return f"print({dump(value)})" case Operation(left, op, right): return f"({dump(left)} {op} {dump(right)})"

Note: This section was largely derived from PEP 622 [4]_.

Rationale =========

Kotlin [5]_, Scala 2 [6]_, and Java 17 [7]_ all support a ``sealed`` keyword that is used to declare algebraic data types. By using the same terminology, the ``@sealed`` decorator will be familiar to developers familiar with those languages.

Specification =============

The ``typing.sealed`` decorator can be applied to the declaration of any class. This decoration indicates to type checkers that all immediate subclasses of the decorated class are defined in the current file.

The exhaustiveness checking features of type checkers should assume that there are no subclasses outside the current file, treating the decorated class as a ``Union`` of all its same-file subclasses.

Type checkers should raise an error if a sealed class is inherited in a file different from where the sealed class is declared.

A sealed class is automatically declared to be abstract. Whatever actions a type checker normally takes with abstract classes should be taken with sealed classes as well. What exactly these behaviors are (e.g. disallowing instantiation) is outside the scope of this PEP.

Similar to the ``typing.final`` decorator [8]_, the only runtime behavior of this decorator is to set the ``__sealed__`` attribute of class to ``True`` so that the sealed property of the class can be introspected. There is no runtime enforcement of sealed class inheritance.

Reference Implementation ========================

[Link to any existing implementation and details about its state, e.g. proof-of-concept.]

Rejected Ideas ==============

Generalize ``Enum`` -------------------

Rust [9]_, Scala 3 [10]_, and Swift [11]_ support algebraic data types using a generalized ``enum`` mechanism.

.. code-block:: rust

enum Message { Quit, Move { x: i32, y: i32 }, Write(String), ChangeColor(i32, i32, i32), }

One could imagine a generalization of the Python ``Enum`` [12]_ to support variants of different shapes. But given that the Python ``Enum`` is more or less a normal class, with some magic internals, this would be a much more invasive change.

.. code-block:: python

from dataclasses import dataclass from enum import Enum

class Message(Enum): @dataclass class Quit: ...

@dataclass class Move: x: int y: int

@dataclass class Write: message: str

@dataclass class ChangeColor: r: int g: int b: int

Explicitly list subclasses --------------------------

Java requires that subclasses be explicitly listed with the base class.

.. code-block:: java

public sealed interface Node permits Leaf, Branch {}

public final class Leaf {} public final class Branch {}

The advantage of this requirement is that subclasses can be defined anywhere, not just in the same file, eliminating the somewhat weird file dependence of this feature. Once disadvantage is that requires that all subclasses to be written twice: once when defined and once in the enumerated list on the base class.

There is also an inherent circular reference when explicitly enumerating the subclasses. The subclass refers to the base class in order to inherit from it, and the base class refers to the subclasses in order to enumerate them. In statically typed languages, these kinds of circular references in the types can be managed, but in Python, it is much harder.

For example, this ``Sealed`` base class that behaves like ``Generic``:

.. code-block:: python

from typing import Sealed

class Node(Sealed[Leaf, Branch]): ...

class Leaf(Node): ... class Branch(Node): ...

This cannot work because ``Leaf`` must be defined before ``Node`` and ``Node`` must be defined before ``Leaf``. This is a not an annotation, so lazy annotations cannot save it. Perhaps, the subclasses in the enumerated list could be strings, but that severely hurts the ergonomics of this feature.

If the enumerated list was in an annotation, it could be made to work, but there is no natural place for the annotation to live. Here is one possibility:

.. code-block:: python

class Node: __sealed__: Leaf | Branch

class Leaf(Node): ... class Branch(Node): ...

``Union`` of independent variants ---------------------------------

Some of the behavior of ``sealed`` can be emulated with ``Union`` today.

.. code-block:: python

class Leaf: ... class Branch: ...

Node = Leaf | Branch

The main problem with this is that the ADT loses all the features of inheritance, which is rather featureful in Python, to put it mildly. There can be no abstract methods, private methods to be reused by the subclasses, public methods to be exposed on all subclasses, ``__init_subclass__``, etc. Even if a specific method is implemented on each subclass, then rename, jump-to-definition, find-usage, and other IDE features are difficult to make work reliably.

Adding a base class in addition to the union type alleviates some of these issues:

.. code-block:: python

class BaseNode: ...

class Leaf(BaseNode): ... class Branch(BaseNode): ...

Node = Leaf | Branch

Despite being possible today, this is quite unergonomic. The base class and the union type are conceptually the same thing, but have to be defined as two separate objects. If this became standard, it seems Python would be first language to separate the definition of an ADT into two different objects.

The base class is not merely passive, either. There are a number of operations that will only work when using the base class instead of the union type. For example, matching only works on the base class, not the union type:

.. code-block:: python

maybe_node: Node | None = ... # must be Node to enforce exhaustiveness

match maybe_node: case Node(): # TypeError: called match pattern must be a type ... case None: ...

match maybe_node: case BaseNode(): # no error ... case None: ...

Having to remember whether to use the base class or the union type in each situation is particularly unfriendly to the user of a sealed class.

Footnotes =========

.. [1] https://en.wikipedia.org/wiki/Pattern_matching

.. [2] https://en.wikipedia.org/wiki/Algebraic_data_type

.. [3] https://docs.python.org/3/library/typing.html

.. [4]

https://peps.python.org/pep-0622/#sealed-classes-as-algebraic-data-types

.. [5] https://kotlinlang.org/docs/sealed-classes.html

.. [6] https://docs.scala-lang.org/tour/pattern-matching.html

.. [7] https://openjdk.java.net/jeps/409

.. [8] https://peps.python.org/pep-0591/

.. [9] https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html

.. [10] https://docs.scala-lang.org/scala3/reference/enums/adts.html

.. [11] https://docs.swift.org/swift-book/LanguageGuide/Enumerations.html

.. [12] https://docs.python.org/3/library/enum.html

Copyright =========

This document is placed in the public domain. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: tinchester@gmail.com

Alternative to Union Types

As shown, union types can be used to represent alternatives of several different types, without requiring those types to be part of a custom-crafted class hierarchy, or requiring explicit wrapping.

Pre-planning the Class Hierarchy Other languages would require pre-planning of the class hierarchy, like

[Responding to John Hagen] Thanks for writing up the PEP. However, like Eric, I'm strongly negative on this proposal. I find it unergonomic and not worth it for the benefits it claims to add. ## Favor Composition over Inheritance On a high level, we want to favor composition over inheritance. With `sealed`, we would be restricted to classes being defined in the same module and all part of a fixed class hierarchy. With union types, we can freely mix and match library classes and user-defined classes. And we can use a class as part of any number of unions, in any module. A *very* common pattern I see with type aliases is to have a large union of types imported from various modules, including third-party libraries. (For open-source examples, see [1].) This flexible mixing would not be possible with sealed classes: ``` from foo import Foo from bar import Bar MyUnion = Foo | Bar | ... def foo(x: MyUnion) -> int: if isinstance(x, Foo): return x.foo_method() if isinstance(x, Bar): return x.bar_method() ``` ## Scala and Kotlin: Sealed Classes for the Lack of Union Types You mention Scala as a language that has sealed types. But Scala only got union types in Scala 3 [2]. They were restricted to sealed classes before that. Their own docs point out the weaknesses of sealed classes/traits compared to union types [3]: the following example illustrates:

trait UsernameOrPassword case class Username(name: String) extends UsernameOrPassword case class Password(hash: Hash) extends UsernameOrPassword def help(id: UsernameOrPassword) = ...

Pre-planning does not scale very well since, for example, requirements of

Union types would make a big difference in Kotlin. At the moment, a sealed class is the closest thing to a union type, but it has several

API users might not be foreseeable. Additionally, cluttering the type hierarchy with marker traits like UsernameOrPassword also makes the code more difficult to read. The other reason Scala needed explicit case classes was to enable pattern-matching, since case classes automatically derive the necessary `unapply` method [6]. Python's structural pattern-matching doesn't have that limitation. Kotlin also lacks union types, and the language designers seem to frequently mention the same downsides as above [4]: limitations, the biggest being that you can only have subtypes defined by you as part of a sealed class.

[PEP] A design pattern where a group of record-like classes is combined into a union is popular in other languages that support pattern matching

TypeScript's type system is closer to Python's than Scala or Java. And TypeScript heavily uses union types for exhaustive pattern-matching. ## Motivating Example I found your motivating code snippet pretty hard to understand when it was written using `sealed`. We have to make each of the classes inherit from the sealed superclass. This is cumbersome for users and ties them down to a class hierarchy. This goes against the spirit of static duck typing, where we shouldn't have to reach into a class definition and add a parent just to make it acceptable to the type system. With `sealed`, we are limited to classes defined by the user in the same module. In real-world code, I find a lot of examples of unions of types imported from different modules, but very few of the same-module classes that you have. How often do you think this will be used? The PEP's approach also requires us to define empty shell classes for `Node`, `Expression`, or `Statement`. Finally, to understand the intended meaning of the `Expression` class, I have to go over the rest of the file and hunt for its subclasses (which could be anywhere in the module). That kind of non-local reasoning is highly unintuitive. With a union, `Expression = Name | Operation`, I can see the components of `Expression` right where it is defined. Contrast the motivating example to the more idiomatic `Union` version, where we have independent classes: ``` from __future__ import annotations from typing import * from dataclasses import dataclass @dataclass class Name: name: str @dataclass class Operation: left: Expression op: str right: Expression @dataclass class Assignment: target: str value: Expression @dataclass class Print: value: Expression Expression = Name | Operation Statement = Assignment | Print Node = Expression | Statement def dump(node: Node) -> None: match node: case Assignment(target, value): reveal_type(target) reveal_type(value) case Print(value): reveal_type(value) case Operation(left, op, right): reveal_type(left) reveal_type(op) reveal_type(right) case _: assert False ``` The above works just fine in Pyright. I also tested something similar in Pyre [5]. ## Specification

Once disadvantage [of explicitly listing subclasses, as in Java] is that requires that all subclasses to be written twice: once when defined and once in the enumerated list on the base class.

Doesn't your proposal also require the base class to be written an extra time for each subclass? For example, in your motivating example, Node, Expression, and Statement are repeated for each subclass. ## Rejected Ideas

Having to remember whether to use the base class or the union type in each situation is particularly unfriendly to the user of a sealed class.

Agreed that this is a drawback of the union approach. But this seems minor given that the example was somewhat contrived: the user matched on `Node | None` and did nothing with the `Node` branch. The most common use case is where we are matching on the individual variants of `Node`: `Expression`, `Statement`, etc. As Thomas (tmkehrenberg) mentioned:

Unions do support isinstance since python 3.10 but apparently they do not support pattern matching. This feels like an oversight to me.

That should be a reasonable solution to this problem. Even without that, I don't think this is a significant drawback. ## Conclusion It looks like the main benefits proposed by this PEP are: 1. Not having to import base classes in the cases where we want to match on the whole union instead of matching the individual variants. This seems like a minor benefit and can be addressed by allowing Unions in match. 2. Automatic exhaustiveness-checking: That is, if the match statement for `Node` doesn't check for `Name`, the type checker should warn about it. This is currently already expressible in 3.11 using Jelle's `case _: assert_never()`. Yes, this is cumbersome to add, but it's not always illegal to leave out a case branch. In cases where it is illegal - say, if each case branch defines a variable, but there is no case branch for `Name` - then the type checker already complains about it. For example: ``` match node: case Assignment(target, value): x = 1 case Print(value): x = 2 case Operation(left, op, right): x = 3 print(x) # Pyright: "x" is possibly unbound (since there was no branch for Name) ``` A better solution for your use case might be to have type checkers complain about missing case branches in their "strict" mode. That should satisfy users who want `match` to check for exhaustiveness without `assert_never`, while avoiding unnecessary noise for most users. Other than these two minor benefits, I don't see any compelling advantages. There are many downsides, such as: 1. Not being able to create an ADT using existing types. 2. Tying the user to a class hierarchy. 3. Causing unidiomatic code, with empty base classes that need to be repeated for each subclass and non-local reasoning needed to understand the meaning of the sealed base class. If we want "versatile ADTs", unions are much more flexible and versatile than the `@sealed` alternative, while providing similar exhaustiveness-checking. So, I'm strongly negative on this PEP. [1]: https://grep.app/search?q=%3D%20Union%5B&case=true&filter[lang][0]=Python [2]: http://dotty.epfl.ch/docs/reference/new-types/union-types-spec.html [3]: https://docs.scala-lang.org/scala3/book/types-union.html#alternative-to-unio... [4]: https://discuss.kotlinlang.org/t/union-types/77/103 [5]: shorturl.at/acF26 [6]: https://docs.scala-lang.org/overviews/scala-book/case-classes.html#an-unappl... On Sat, May 7, 2022 at 5:16 PM Guido van Rossum <guido@python.org> wrote:

On Sat, May 7, 2022 at 4:39 PM Tin Tvrtković <tinchester@gmail.com> wrote:

...

Just like Eric, appreciate the work that has gone into this. I am excited by the idea of ADTs since they are a key part of making invalid state unrepresentable, which is amazing for software correctness. However, I would be disappointed if this version of ADTs was accepted since I think basing our ADTs on the Pythonized version of the Rust syntax would be more usable and elegant. The argument given against it is that this would be a more invasive change, which may not matter for us to get it right the first time?

Rust-style enums containing both classes and values would be my ideal scenario. I'm very happy to share actual examples from work where I've wished I had robust ADTs if that would help.

Few people here know Rust. (At least I'll admit that *I* don't know it.) I don't believe actual examples from your work would be that helpful (without knowing Rust I wouldn't be able to understand them). But perhaps you could sketch out a counter-proposal with a Pythonic syntax and some tutorial examples? (More than foo+bar, less than real-world code.) I certainly am not married to the @sealed syntax, it's just the only thing I feel I have a decent understanding of (roughly, "final outside this module").

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: gohanpra@gmail.com

-- S Pradeep Kumar

Rust-style enums containing both classes and values would be my ideal scenario. I'm very happy to share actual examples from work where I've wished I had robust ADTs if that would help.

I am sympathetic to Rust-style enums (subclasses listed inside the body of the base class). The problem is getting this to work with inheritance in Python. Rust doesn't have inheritance, so it doesn't care. Scala and Swift have a compiler that handles it. The obvious design (the rejected one in the PEP) would use the `class` keyword within the base class body. The problem is that the base class does not exist at this point (at least not under its name), so something like this will not work: ``` from enum import Enum class Result(Enum): class Success(Result): ... class Failure(Result): .... ``` We could have `Enum` do some magic (on top of what it does right now) that it injects itself into the `__bases__` of any class object found among its attributes. Or `Enum` could rebuild each class object found with itself added to the list of bases. This may be worth exploring more, because there are a number of edge cases that I don't know how to deal with from an implementation perspective.

Sorry if I gave the wrong impression, I work in Python so my examples would be Python. In any case, the PEP gives this Rust example: ``` enum Message { Quit, Move { x: i32, y: i32 }, Write(String), ChangeColor(i32, i32, i32), } ``` and then it proceeds to translate it into Python a few lines below. This is useful since it's an ADT with both classes and values (Message.Quit is a value - you can't instantiate it). This is possible today in Python, like this: ``` class MessageValue(Enum): QUIT = "quit" @dataclass class Move: x: int y: int @dataclass class Write: msg: str @dataclass class ChangeColor: r: int g: int b: int Message = MessageValue | Move | Write | ChangeColor ``` but it's verbose and disjointed. (Here's how this would be used: ``` def process_message(m: Message) -> None: match m: case MessageValue.QUIT: print("quit") case Move(x, y): print(f"move: {x} {y}") case Write(msg): print(f"write: {msg}") case ChangeColor(): print("change color") case _ as x: assert_never(x) ```) I propose adding some magic, so we get this instead: ``` class Message(Enum): QUIT = "quit" @dataclass class Move: x: int y: int @dataclass class Write: msg: str @dataclass class ChangeColor: r: int g: int b: int ``` with the same semantics as `Message` in the first example. (The dataclasses are *inside* the Message enum.) Given a Python Enum, type checkers already semantically treat it as a Union of its values. We extend this union to contain instances of classes defined inside. If backwards comp is an issue, we add a different base class in the enum module (so it'd be `Message(ADT)` instead of `Message(Enum)`. On Sun, May 8, 2022 at 2:16 AM Guido van Rossum <guido@python.org> wrote:

Few people here know Rust. (At least I'll admit that *I* don't know it.) I don't believe actual examples from your work would be that helpful (without knowing Rust I wouldn't be able to understand them). But perhaps you could sketch out a counter-proposal with a Pythonic syntax and some tutorial examples? (More than foo+bar, less than real-world code.) I certainly am not married to the @sealed syntax, it's just the only thing I feel I have a decent understanding of (roughly, "final outside this module").

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

On 5/8/2022 5:01 PM, David Hagen wrote:

I am sympathetic to this design. Right now, `Enum` rewrites that `"quit"` value so that `Message.QUIT` is not actually equal to `"quit"`, but is actually an instance of `Message`. If the syntax of `Enum` was expanded to allow not just values, but classes, then `Move`, `Write`, and `ChangeColor` would have to be rebuilt to be subclasses of `Message`. I am not sure what all the implications of that would be. I remember there was hesitation toward having dataclasses add `__slots__` because it required rebuilding each class from scratch [1], but that was ultimately resolved in favor of rebuilding [2]. I have not heard any horror stories about dataclass slots, so maybe it's ok.

There are definitely some problems with returning a new class for slots=True. For example, zero-argument super is broken: https://github.com/python/cpython/issues/90562 I'm sure there are others. Eric

On 2022-05-08, at 13:04, David Hagen <david@drhagen.com> wrote:

...

Rust-style enums containing both classes and values would be my ideal scenario. I'm very happy to share actual examples from work where I've wished I had robust ADTs if that would help.

I am sympathetic to Rust-style enums (subclasses listed inside the body of the base class). The problem is getting this to work with inheritance in Python. Rust doesn't have inheritance, so it doesn't care. Scala and Swift have a compiler that handles it.

The obvious design (the rejected one in the PEP) would use the `class` keyword within the base class body. The problem is that the base class does not exist at this point (at least not under its name), so something like this will not work:

``` from enum import Enum

class Result(Enum): class Success(Result): ...

class Failure(Result): .... ```

We could have `Enum` do some magic (on top of what it does right now) that it injects itself into the `__bases__` of any class object found among its attributes. Or `Enum` could rebuild each class object found with itself added to the list of bases. This may be worth exploring more, because there are a number of edge cases that I don't know how to deal with from an implementation perspective. _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jakub@stasiak.at

Hey all, this reminds me that I actually played with the idea of Rust-like enums in Python a while ago and this is what I came up with: https://gist.github.com/jstasiak/7f1687100ec7b2000b5206a537b1a0b0 I focused on what kind of API I wanted and the support for all types of members that Rust has: singletons, "tuple structs" and regular structs. An excerpt: @enum class WebEvent: PageLoad: None KeyPress: tuple[str] class Click: x: int y: int def inspect(event: WebEvent) -> None: match event: case WebEvent.PageLoad: print("Page loaded") case WebEvent.KeyPress(c): print(f"Pressed key {c}") case WebEvent.Click(x=x, y=y): print(f"Clicked on {x}/{y}") Best, Jakub

Hi Matthias, There has been some back-and-forth during the years on how to improve sum types in Python in this community, but lately personally I've come to the realization the existing infrastructure (unions, enums, literals) is very good already. Are unions enough for your use case? ``` @dataclass class Rectangle: width: float length: float @dataclass class Circle: radius: float @dataclass class Prism: width: float height: float Shape = Rectangle | Circle | Prism ``` You can exhaustively match on this if you know the `assert_never` trick, and I find it works very well. On Mon, Mar 20, 2023 at 3:29 PM Matthias Gramberg via Typing-sig < typing-sig@python.org> wrote:

I come from the FSharp community.

Thanks for considering this, ADTs are particularly missing for me in today's Python. I am used to structure all my code with them, and so is the whole community at F#.

One thing I like to mention regarding the naming:

@choice class

I how I would define it. Not only does it say, what it does (opposite to how its implemented) it also aligns nicely with

@data class

@sealed doesn't say much about its usage.

I am also interested about the syntax for "the next stage of the object", like in:

type Shape = | Rectangle of width : float * length : float | Circle of radius : float | Prism of width : float * float * height : float

How would you do that? _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: tinchester@gmail.com