There seems to be a movement (inspired by Haskell no doubt) that argues that sum types are the next fashion in language design. E.g. Googling for "sum types python" I found (I should look up the author, he works a floor away from me :-).

If you read that carefully, a sum type is mostly syntactic sugar for a tagged union. They're easy enough to add to compiled languages. I find it interesting that Austin mentions several types that the "Maybe" type is equivalent to the convention of returning NULL/null/None, and he uses it as a simple example (the simplest, in fact) of a sum type. So in PEP 484 that's called Optional[X], and indeed Optional[X] is syntactic sugar for Union[X, None], and of course unions in Python are always tagged (since you can always introspect the object type).

So Python's equivalent for Sum types seems to be PEP 484's Union types. For matching, a sequence of isinstance() checks doesn't look too shabby:

def add1(a: Union[int, str, bytes]) -> Union[int, str, bytes]:
    if isinstance(a, int):
        # In this block, the type of a is int
        return a+1
    if isinstance(a, str):
        # Here a is a str
        return a + 'x'
    # In this block, the type of a is bytes (because it can't be anything else!)
    return a + b'x'

Of course in this specific example, using a constrained type variable (similar to AnyStr) would be much better, since it declares that the return type in this case is the same as the argument type. However that's not what Sum types do in Haskell either, so we can't really blame them for this -- in Haskell as in PEP 484, Sum types and generics are pretty much orthogonal concepts. I think Sum/Union shine when they are either used for the argument (so the function must have a list of cases) or for the return value so the caller must have a list of cases), but not for both.

That's not to say that it wouldn't be an interesting exercise to see if we can add a nice pattern matching syntax to Python. Austin claims that one of the advantages of Sum types in Haskell is that it supports a recursive matching syntax. It would probably look different than it looks in compiled languages though, because a Python compiler doesn't know much about the types occurring at runtime, so e.g. it couldn't tell you when you're missing a case. However, a type checker could -- this might be the first new Python feature that was in some sense enabled by PEP 484.

(And here I thought I was off-topic for the thread, but this thread was actually started specifically to discuss Sum types, so now I feel better about this post.)

PS. I recall vividly the classes in category theory I took in college. They were formative in my education -- I knew for sure then that I would never be a mathematician.

On Sun, May 15, 2016 at 4:37 PM, Greg Ewing <> wrote:
Koos Zevenhoven wrote:

Maybe you mean to propose that the concept of sum types should be
introduced in typing/mypy.

I'm not deeply into category theory, but the proposal
seems to be that Sum would be a special kind of type
that's assumed to be the same type wherever it appears
in the signature of a function.

That might work for the special case of a function of
one parameter that returns the same type as its
argument, but that's about all.

As has been pointed out, type parameters allow the
same thing to be expressed, and a lot more besides,
so a Sum type is not needed. We already have everything
we neeed.


Python-ideas mailing list
Code of Conduct:

--Guido van Rossum (