22 points sebg 1 day ago 9 comments

chowells 1 hour ago | parent

I like it. I can't see how to do better while remaining compatible with Python idioms.

RantyDave 1 hour ago | parent

"A simple cache returns None both for a missing key and for a key that maps to None."

No, it returns KeyError. Or at least it should.

lyorig 55 minutes ago | parent

Perhaps the author has had their fair share of run-ins with libraries that didn't think their API through like that. But yes, they should.

travisd 39 minutes ago | parent

it’s maybe less “pythonic” but at $dayjob we’ve very actively moved away from exceptions for things in favor of things that are statically type checked. too many things that become runtime bugs instead of type checking bugs.

with match now being available, we even return explicit error objects and the ergonomics are pretty good (reminds me of rust).

lpghatguy 50 minutes ago | parent

When I was writing a bunch of Lua, I was a big fan of having a None sentinel value (Lua uses 'nil' for representing absence) and it was useful for a lot of things similar to Pydantic's MISSING.

This distinction is something that I think is actually handy about JavaScript, and distinguishing between 'null' and 'undefined' is sometimes useful for similar reasons.

pwdisswordfishq 20 minutes ago | parent

So much trouble to avoid introducing the optional monad.

woodruffw 15 minutes ago | parent

Python’s type system has union types (including Option), and using them is pretty ergonomic. As TFA points out the problem is that `None` gets contextually reused in all kinds of places where a proper sentinel type is more appropriate.

Waterluvian 13 minutes ago | parent

I’m curious what that would practically look like in Python.

I bet this would be a good use of vibe coding. Experiment with what-ifs. I can imagine being able to “show not tell” and reduce the signal-to-noise of comment opinions.