[Python-ideas] "Sum" Type hinting [was: Type hinting for path-related functions]

Guido van Rossum guido at python.org
Sun May 15 21:57:07 EDT 2016


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 https://chadaustin.me/2015/07/sum-types/ (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 <greg.ewing at canterbury.ac.nz>
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.
>
> --
> Greg
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160515/2cbb5768/attachment.html>


More information about the Python-ideas mailing list