Hacker News Reader

Comment by IshKebab | Hacker News Reader

Yeah this sort of thing is necessary in statically typed languages like Rust and C++ but in Python (and e.g. Typescript) you can just use anonymous type unions like `str | None`.

There's no need to construct a static type to hold both possibilities because variables can already hold all types.

View on HN

Good luck checking for `None` equality and indent your code like 5 times... a sort of railway programming[0] avoids the awkward checks for values, making functions work with higher order types.

0: https://www.greenbird.com/news/railway-oriented-programming-....

The original Railway:

https://fsharpforfunandprofit.com/rop/

And his 'Against Railway-Oriented Programming':

https://fsharpforfunandprofit.com/posts/against-railway-orie...

How is this different from match case ok case err or from if result.val?

Well, the most basic pro is to avoid indentation and have pure function which are clear and have less assumption to take into account; if I know that my pipes always return me a result such as the one I want, and the "bad path" is discarded automatically, code is way cleaner.

Imagine a code without `if result is not None` basically!

  if a is None:
    raise Exception()
  if a.b is None:
    raise Exception()
  if a.b.c is None:
    raise Exception()

One of the advantages of Python/Typescript style type hinting is that it avoids the mega-nested `if`s that you often have to resort to in Rust. In Rust the above would not work:

  if a.is_none() {
    bail!();
  }
  if a.b. // nope! a is still Option<>.

It may be possible to fix that when enum variants are distinct types but as it stands you often have to do lots of indenting.

  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.

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.

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.

Reply on news.ycombinator.com