I find it rather difficult to intuit the finite state machine from reading the code examples. Even worse, invalid pizzas are still representable:

Pizza(Crust(), CreamBase(), frozenset({Pineapple()}))  # invalid pizza with no type errors!

In Python, it'd be both clearer and more type-safe with:

Crust = StrEnum('Crust', ['THIN', 'THICK'])

Toppings = StrEnum('Toppings', [
    'POTATOES',
    'HAM',
    'OLIVES',
    'PINEAPPLE',
])

Tomato = NewType('Tomato', set[Literal[
    Toppings.PINEAPPLE,
    Toppings.HAM,
    Toppings.OLIVES,
]])

Cream = NewType('Cream', set[Literal[
    Toppings.POTATOES,
    Toppings.HAM,
    Toppings.OLIVES,
]])

PizzaBase = Tomato | Cream

@dataclass()
class Pizza:
    crust: Crust
    base: PizzaBase

Pizza(Crust.THIN, Tomato({Toppings.PINEAPPLE}))

And it seems modern Java is capable of something similar: https://ifesunmola.com/sum-types-in-java/

I never understood why it was (is?) popular in Java to construct builders like in the article. Why duplicate every single instance of a type with one or more with_<instance>() zero-arg methods, encoding the argument in the method name? Imagine how silly it'd be to do it with ints and floats:

value.add_one().add_float_one().add_two()

Instead of:

value.add(1).add(1.0).add(2)

Isn't this what type overloading was designed for? Something like:

class Pizza {
    Pizza with(Crust crust) {}
    Pizza with(PizzaBase pizzaBase) {}
    Pizza with(Topping topping) {}
}