On Wed, May 18, 2016 at 3:41 PM, Greg Ewing firstname.lastname@example.org wrote:
Guido van Rossum wrote:
your original remark claimed something wasn't syntactic sugar because of the difference between the box and its contents, and that's what I disagree with.
Maybe I misunderstood -- you seemed to be saying that algebraic types were just syntactic sugar for something. Perhaps I should have asked what you thought they were syntactic sugar *for*?
That's a good question, for which I don't have a great answer. I've just discussed some of this with the author of that blog article (Chad Austin) and we came to the conclusion that there isn't a great future for ADTs or Sum types in Python because almost everything you can do with them already has a way to do it in Python that's good enough.
Sometimes what you need is Haskell's Maybe (i.e. 'Nothing' or 'Just x'), and in most cases just checking for None is good enough. The strict optional checking that's coming to mypy soon will help here because it'll catch you when you're not checking for None before doing something else with the value.
Sometimes you really do want to distinguish between the box and what's in it, and then you can use a bunch of simple classes, or maybe a bunch of namedtuples, to represent the different kinds of boxes. If you declare the unopened box type as a Union you can get mypy to check that you've covered all your bases. (If you don't want/need a check that you're handling all cases you can use a shared superclass instead of a union.)
There are probably a few other cases.
The one thing that Python doesn't have (and mypy doesn't add) would be a match statement. The design of a Pythonic match statement would be an interesting exercise; perhaps we should see how far we can get with that for Python 3.7.
I was also responding to a comment that values in Python are already tagged with their type, so tagged unions are unnecessary. But the type tag of a Python object is not equivalent to the tag of an algebraic type, because the latter conveys information over and above the type of its payload.
Right. And if you need that feature you can wrap it in a class or namedtuple.