Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't let dicts spoil your code

roman.pt

Post reply on HN
Print view View original

61–70 of 121 posts

Re: Don't let dicts spoil your code

#61

Post by bloppe »

ungamedplayer wrote: post #51

Can someone educate me in why dicts are uncool for explained reasons, but clojure (which seems to be highly recommended on hn) seems to suffer the same issues when dealing with a map as a parameter (ring request etc). I know how to deal with missing values or variability in maps, and so do a lot of people.. what am I missing here?

Dicts are great when the data is uniform and dynamic, like an address book mapping names to contact info. You never assume that a key must be in there. Lookups can always fail. That's normal for this kind of use-case.

When the data is not uniform (different keys point to differently-typed values), and not as dynamic (maybe your data model evolves over time, but certain functions always expect certain keys to be present), a dict is like a cancer. Sure, it's simple at first, but wait until the same dict gets passed around to a hundred different functions instead of properly-typed parameters. I just quit my job tech at a company that shall remain nameless, partially because the gigantic Ruby codebase I was working on had a highly advanced form of this cancer, and at that point it was impossible to remove. You were never sure if the dict you're supplying to some function had all the necessary keys for the function it would eventually invoke 50 layers down the call stack. But, changing every single call-site would involve such a major refactor that everybody just kept defining their functions to accept these opaque mega-dicts. So many bugs resulted because of this. That was far from the only problem with that codebase, but it was a major recurring theme.

I learned this lesson the hard way.

Re: Don't let dicts spoil your code

#63

Post by pansa2 »

pansa2 wrote: post #60

> convert [dicts] immediately to data structures providing semantics [...] You can simplify your work by employing a library that makes “better classes” for you Python seems to have many different kinds of "better classes" - the article mentions `dataclass` and `TypedDict`, and AFAIK there are also two different kinds of named tuple (`collections.namedtuple` and `Typing.NamedTuple`). What are the advantages of these…

To me, the proliferation of "better classes" implies there's a problem with Python's built-in classes - but what's wrong? Are they just too flexible and/or too verbose? Or actually deficient in some way?

Re: Don't let dicts spoil your code

#64

Post by jmorenoamor »

sosotrue wrote: post #62
Jean-Papoulos wrote: post #56

>"unstructured data is problematic" >"solution : use dataclasses" Damn, it's almost like using an untyped language for large projects is not a great idea.

[flagged]

Dynamic languages demand self discipline, they teach you to respect runtime and think ahead of execution time.

I've written software with both typed and untyped languages and never had problems (out of the ususal) with them.

Re: Don't let dicts spoil your code

#65

Post by jrjrjrjrj »

jmorenoamor wrote: post #64
sosotrue wrote: post #62

Earlier quoted context omitted.

[flagged]

Dynamic languages demand self discipline, they teach you to respect runtime and think ahead of execution time. I've written software with both typed and untyped languages and never had problems (out of the ususal) with them.

I would argue that dynamic languages make a compile time problem a run time problem...

So yeah that small not hit portion of code can always be a time bomb if it does not get tested...

Re: Don't let dicts spoil your code

#66

Post by directevolve »

ramraj07 wrote: post #27
est wrote: post #22

dicts are OK, because at least they do have a `key` and it does mean something. un-annotated tuples and too many func params are cancer.

Who does this still??

In bioinformatics, one of our main dataflow platforms, Nextflow, is built with unnamed tuples in mind. Implementing the ability to conveniently pass data with HashMaps instead of unnamed tuples was a huge boost to usability for me.

Re: Don't let dicts spoil your code

#67

Post by Garlef »

I don't think dicts themselves are the problem.

In typescript using plain JS objects is very straightforward. Of course you have to validate the schema at your system boundaries. But you'll have to do this either way.

So: If this works very well in TS it can't be dicts themselves but must be the way they integrate into- and are handled in python.

This leads me to the conclusion that arguments presented in the article might be the wrong ones.

(But I still think, the conclusion the article arrives at is okay. But I don't think there's a strong case being made in the article about wether to prefer data classes or typed dicts.)

Re: Don't let dicts spoil your code

#68

Post by CraigJPerry »

This has merit in some cases but let me try to make a counterpoint.

You lose the algebra of dict’s - and it’s a rich algebra to lose since in python it’s not just all the basic obvious stuff but it’s also powerful things like dict comprehensions and ordering guarantees (3.7+ only).

You tightly couple to a definition - in the simple GitHubRepository example this is unlikely to be problematic. In the real world, coupling like this[1] to objects trying to capture domain data with dynamic structures is regularly the stuff of nightmares.

The over-arching problem with the approach given is that it puts code above data. You take what could be a schema, inert data about inert data, and instead use code. But it might also be an interesting case to consider as a slippery slope - if you can put code concerns above data concerns then maybe soon you will see cases where code concerns rank higher than the users of your software?

[1] - by coupling like this I mean the “parse don’t validate” school of thought which says as soon as you get a blob of data from an external source, be it a file, a database or in this case a remote service, you immediately tie yourself to a rocket ship whose journey can see you explosively grow the number of types to accurately capture the information needed for every use case of the data. You could move this parsing operation to be local to the use case of the data (much better) rather than have it here at the entry point of the data to the system but often times (although not always) we can arrive at a simpler solution if we are clever enough to express it in a style that can easily be understood by a newbie to programming. That often means relying on the common algebra of core types rather than introducing your own types.

Re: Don't let dicts spoil your code

#69

Post by orf »

ungamedplayer wrote: post #51

Can someone educate me in why dicts are uncool for explained reasons, but clojure (which seems to be highly recommended on hn) seems to suffer the same issues when dealing with a map as a parameter (ring request etc). I know how to deal with missing values or variability in maps, and so do a lot of people.. what am I missing here?

They also work fine with JavaScript.

The issue is that the concrete types are implicit. Depending on the language, runtime or type system expressing the type in a “better” way might be very hard or un-ergonomic.

Re: Don't let dicts spoil your code

#70

Post by jonathrg »

jimmytucson wrote: post #14

Here’s an out-there take, but one I’ve held loosely for a long time and haven’t shed yet: dicts are not appropriate for what people mostly use them for, which is named access to member attributes. dict is an implementation of a hash table. Hash table are designed for o(1) lookup of items. As such, they are arrays which are much bigger than the number of items they store, to allow hashing items into integers and sides…

dicts are used internally in the language to look up class and module attributes. They are optimized for this use case. How can it be wrong to use them that way when the very fabric of the language depends on it?

namedtuple is widely used in Python code, especially before the introduction of dataclasses.

Post reply on HN