Hacker News Reader

Comment by dragonwriter | Hacker News Reader

  foo | None

is not a tolerable replacement for

  Maybe(foo)

When None is a valid value of type foo.

Which is obviously true when foo is NoneType, but more to the point is true when foo is (bar | None).

Maybe composes, “... | None” does not.

View on HN

I've definitely hacked my way around this with sentinels. `foo | sentinel | None` is a passable replacement for Maybe(foo), and it arises naturally from dict.get("key", SENTINEL). Absolutely not fun to need to check, but if you're using it within a single function e.g. an implementation of `deep_get` or something like that, the code is readable.

Yeah, there's lots of things that work good enough for localized use to approximate something like Maybe or Result and a lot of times that's all you need, and (in Python) more convenient than the real thing when that's all you need.

Wanting something that's ergonomic for free composition where you aren't anticipating all the potential uses where it is defined is where real monadic Maybe/Result types shine, and once you pull them in to a code base it sometimes makes sense to use them for the local cases, too.

a) do Optional[Union[foo, bar]] b) why do you expect this from a duck typed language? None of options you listed or the library is offering saves you from mismatched types. Mypy is still as good as it can possibly be using only vanilla type hints

> None of options you listed or the library is offering saves you from mismatched types.

Even if true, so what? The utility of Maybe/Result datastructures isn't limited to their use in typechecking, though with a proper static typechecker, that is part of their use.

Reply on news.ycombinator.com