News for hackers. Stuff that matters.
Re:We should be more ambitious with the software we build by saint-evan on Sunday October 25, 2026 @03:33PM (#50235250)
I don't get it... What's the problem? I too prefer getting None as opposed to a key Error which would prolly necessitate a try..catch as opposed just checking for None. I'm having trouble reasoning up a situation where raising a keyError would make any sense over a None for data structures like dicts that could return a value or no value! Help?
Re:We should be more ambitious with the software we build by beecasthurlbow on Sunday October 25, 2026 @03:40PM (#50235311)
KeyError localizes the issue to the lookup (ie “right here this key should be present and it’s not) vs later in the code where it can be hard to trace where the None value came from or how to handle it.
Re:We should be more ambitious with the software we build by saint-evan on Sunday October 25, 2026 @03:56PM (#50235471)
Well... yeah but at the cost of halting your entire program? As opposed to logging?
Re:We should be more ambitious with the software we build by wfn on Sunday October 25, 2026 @04:40PM (#50235851)
Think of it like an assert.

Sometimes you do want some flow to terminate if a schema / data contract is breached, and not have this broken data contract propagate elsewhere / outwards.

And/or, it is a perfectly valid pattern to indeed add try..catch, and contain (hence "localize") the issue there and then. If there is a way to handle this breach - you will need some kind of if check anyway. Catching by matching against the particular KeyError exception is in fact robust - and if you forgot to add an intended catch, then the exception will propagate upstack, yes - which is what you want - and this way you do not need to worry about forgetting an "if None" check.

This sort of approach makes it structurally impossible to "forget" - if exception is not caught, it will abort the cannot-be-null breach continuing with program flow, possibly (e.g.) ending up persisted in some place it shouldn't be, causing problems later.

Re:We should be more ambitious with the software we build by saint-evan on Sunday October 25, 2026 @05:55PM (#50236414)
yes, that makes sense. Thank yu so much!
Re:We should be more ambitious with the software we build by zahlman on Monday October 26, 2026 @10:52AM (#50244776)
Python uses `except`, not `catch`.
Re:We should be more ambitious with the software we build by wfn on Monday October 26, 2026 @11:33AM (#50245498)
...sure, that's true :) but you get the point. p.s. and the software design pattern applies in general, imho.
Re:We should be more ambitious with the software we build by sirsinsalot on Sunday October 25, 2026 @07:59PM (#50237272)
Or you know, test if the key exists before using it. The key could exist and be None, representing a legitimate None at that key. Or the key might not exist and asking for it is a bug.

Use a defaultdict if you must have all keys optional. Using get() everywhere is buggy because it masks illegal key use.

Re:We should be more ambitious with the software we build by Chaosvex on Monday October 26, 2026 @04:29AM (#50240786)
> test if the key exists

Double lookup.

Re:We should be more ambitious with the software we build by sirsinsalot on Monday October 26, 2026 @06:11AM (#50241511)
Cheaper than fixing bugs due to illegal key access.

Cheaper than get() masking bugs in your code or dict generation.

But yes let's prematurely optimise for speed in a slow-by-default language by writing bug prone non-idiomatic code. OK.

Re:We should be more ambitious with the software we build by Windchaser on Monday October 26, 2026 @05:04PM (#50250929)
There are times where you want to check for existence before fetching a key-value pair, and there are times where you want to automatically throw an error if the value doesn't exist.

Both have valid use cases. It's weird to be sarcastic about it.