Approximating sum types in Python with Pydantic

I think it would be useful to differentiate more clearly between what is offered by Python's type system, and what is offered by Pydantic.

That is, you can approximate Rusts's enum (sum type) with pure Python using whatever combination of Literal, Enum, Union and dataclasses. For example (more here[1]):

  @dataclass
  class Foo: ...
  @dataclass
  class Bar: ...
  
  Frobulated = Foo | Bar

Pydantic adds de/ser, but if you're not doing that then you can get very far without it. (And even if you are, there are lighter-weight options that play with dataclasses like cattrs, pyserde, dataclasses-json).

[1] https://threeofwands.com/algebraic-data-types-in-python/

The problem I see with it is this: Now, instead of understanding Python, which is straightforward, you have to understand a bunch about Pydantic and type unions. In a large shop of Python programmers, I would expect many would not follow most of this.

Essentially, if this is a feature you must have, Python seems like the wrong language. Maybe if you only need it in spots this makes sense...

One caveat of the tip in the "Deduplicating shared variant state" section about including an underspecified discriminator field in the base class, is that it doesn't play well if you're using Literals instead of Enums as the discriminator type. Python does not allow you to narrow a literal type of a field in a subclass, so the following doesn't type check:

  from typing import Literal
  
  class _FrobulatedBase:
      kind: Literal['foo', 'bar']
      value: str
  
  class Foo(_FrobulatedBase):
      kind: Literal['foo'] = 'foo'
      foo_specific: int
  
  class Bar(_FrobulatedBase):
      kind: Literal['bar'] = 'bar'
      bar_specific: bool


  "kind" overrides symbol of same name in class "_FrobulatedBase"
    Variable is mutable so its type is invariant
      Override type "Literal['foo']" is not the same as base type "Literal['foo', 'bar']"

https://pyright-play.net/?code=GYJw9gtgBALgngBwJYDsDmUkQWEMo...

Meta comment.

Something I've wondered of late. I keep seeing these articles pop up and they're trying to recreate ADTs for Python in the manner of Rust. But there's a long history of ADTs in other languages. For instance we don't see threads on recreating Haskell's ADT structures in Python.

Is this an artifact of Rust is hype right now, especially on HN? As in the typical reader is more familiar with Rust than Haskell, and thus "I want to do what I'm used to in Rust in Python" is more likely to resonate than "I want to do what I'm used to in Haskell in Python"?

At the end of the day it doesn't *really* matter as the underlying construct being modeled is the same. It's the translation layer that I'm wondering about.

Author of typedload here.

typedload does this without need to pass a "discriminator" parameter.

Just having the types with the same field defined as a literal of different things will suffice.

I've also implemented an algorithm to inspect the data and find out the type directly from the literal field, to avoid having to try multiple types when loading a union. Pydantic has also implemented the same strategy afterwards.

typedload is faster than pydantic to load tagged unions. It is written in pure python.

edit: Also, typedload just uses completely regular dataclasses or attrs. No need for all those different BaseModel, RootModel and understanding when to use them.

A pretty good article. Would be a great article if they used real world examples instead of made up "formulated" ones.

It's a shame there's so many different names for a set of very related (or identical?) concepts. For example wikipedia says "tagged union" is also known as "variant, variant record, choice type, discriminated union, disjoint union, sum type, or coproduct". [https://en.wikipedia.org/wiki/Tagged_union]

Discriminated unions are also a wonderful part of the zod library. I use them to overload endpoints for multiple relevant operations.

As an alternative to Pydantic, check out the wonderful mashumaro: https://github.com/Fatal1ty/mashumaro

I've also played around with writing my own dataclass/data conversion library: https://github.com/hexane360/pane

And people complain that typescript is crazy. I think we just need to acknowledge that typing is hard, especially with what mainstream languages give us.

python has been about expressing ideas. Even if the language doesn't support some of the concepts natively, it's useful to express it in python so it could be effectively transpiled into a language that does. This is what py2many needs from a curated subset of python with some enhancements as opposed to inventing a new language.

https://github.com/adsharma/adt contains a small enhancement for @sealed decorator from the excellent upstream repo.

https://github.com/py2many/py2many/blob/main/tests/cases/sea... https://github.com/py2many/py2many/blob/main/tests/expected/...

A slightly related discussion on Type Unions in C# from a week ago: https://news.ycombinator.com/item?id=41183240

I feel like with typescript and pydantic taking center stage it seems that the dynamic vs static typing debate finally comes to a close.

More and more Java seems to be not that bad after all.

That looks crazy coming from statically-typed languages. So many hops, efforts, custom structures just to verify types. Come on, modern C# can do all of that out-of-the-box. You define a record/class for DTO and System.Text.Json will either convert it successfully or throw you an exception that will say exactly what the problem was and at what character/field. Combined with much more advanced IntelliSense, development comfort is so much better. But of course, whatever works for you.