undefined | Better HN

0 pointsdragonwriter4y ago0 comments

  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.

0 comments

4 comments · 2 top-level

btown4y ago· 1 in thread

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.

dragonwriterOP4y ago

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.

impoppy4y ago· 1 in thread

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

dragonwriterOP4y ago

> 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.

j / k navigate · click thread line to collapse