> but it's added some fragile and/or unintended consequences

In python, in a co-worker's code, it seems to significantly prefer "some_dict.get('key')" over "some_dict['key']". For the non-python-users, the first one will return None (equivalent to null) when the key is missing, while the second raises a KeyError. It was being used in a whole bunch of places that would cause problems (bad data instead of errors) if it did receive None. Some of these keys were actually optional and it does makes sense for those, but it looks like whichever model he was using just repeated the pattern everywhere instead of just where it was appropriate.

▲

saint-evan 10 hours ago | parent | next [-]

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?

▲

beecasthurlbow 10 hours ago | parent | next [-]

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.

▲

saint-evan 9 hours ago | parent [-]

Well... yeah but at the cost of halting your entire program? As opposed to logging?

▲

wfn 9 hours ago | parent [-]

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.

	▲	saint-evan 7 hours ago \| parent [-]
		yes, that makes sense. Thank yu so much!

▲

sirsinsalot 5 hours ago | parent | prev [-]

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.

▲

dirtbag__dad 5 hours ago | parent | prev | next [-]

This to me feels more like a developer skills issue than a problem with the LLM. At my day job, we banned using untyped data structures like this entirely well before LLMs because no one could read code that passed them around.

You could use a data structure that better articulates an optional field, like a dataclass with type hints or a pydantic model. Then you, your coworker, and the agent alike, aren’t guessing at whether the key’s value is optional.

Another example in this vein is having many optional parameters on a function or api route, that drive behavior deeply nested in the application logic. Or maybe they were there for testing and never deleted. No one comes across this code next and understands it easily. How could you expect a LLM to understand it, either?

I find it funny when people blame the LLM for dog shit code, but at the same time have a pollock painting of code they load into its context, and are like “put a person in the horse and carriage!” And the LLM is like “bro I just see dots and squiggles but you asked so boom!”

	▲	Izkata 38 minutes ago \| parent [-]
		The square bracket version tells the reader it's required, the .get version tells the reader it's optional. Kind of the reason both exist in the language (the .get version has an optional second argument to return instead of None when the key is missing).

▲

AgentOrange1234 8 hours ago | parent | prev [-]

Oh man, you're giving me flashbacks to a vibe coded utter mess. Gets were a big offender. It seemed to have no discipline to commit to a data format, added all kinds of optional parameters everywhere, was also doing truly insane things like having contingency fallbacks in case some library it wanted to import wasn't where it expected, sometimes even importing things in the middle of a function.