Live data from Hacker News

Don't let dicts spoil your code (2020)

roman.pt

41–50 of 91 posts

Re: Don't let dicts spoil your code (2020)

#42
* Don't let dicts spoil your python code

Maybe that was implied?

Anyways, a lot of languages take another stance. E. Elixir where using dicts along with pattern matches calls for quite powerful abstractions.

As long as the dicts are kept shallow and the number of indirection in the code in general so, then it is alright to navigate and use.

Re: Don't let dicts spoil your code (2020)

#43
This is something I enforced in a big rewrite at a previous company.

People would take a full API response, and pass bits of it around with mutations. Understanding what the object looked like 5 functions deep was really hard. If the API changed... Oh boy.

I found many bugs just tracing the code like this. It made me a big proponent of strong typing, or at least strong type hinting.

Re: Don't let dicts spoil your code (2020)

#44
post #16

Python's strapped on type annotations have been designed around traditional OOP, and it feels like a bad fit for the language. Duck typing is a tremendously powerful form of polymorphism, and none of the PEPs for type annotations do a great job of supporting it. Protocols don't work well with dataclasses and not at all with dicts. TypedDicts could have been perfect, but they explicitly disallow extra keys. Why even u…

Dealing with all these differences is one of the most frustrating, stupid things about programming today. 99% of the data i deal with on a day-to-day basis is lists and mappings. Very conceptually simple, but with a million different implementations. Particularly in python where we have dicts, namedtuples, dataclasses, regular objects, etc etc etc, then you deal with databases (which are really just mappings of keys…

I completely agree.

You would probably love Clojure. Perhaps you tried it already?

Re: Don't let dicts spoil your code (2020)

#45

Earlier quoted context omitted.

This is one of the things I appreciate about languages like Go and Rust (I'm sure there are others as well). If the data is static, use a struct. If the data is dynamic, use a map/HashMap. No need to worry about TypedDict vs classes vs DataClasses vs etc, and no one uses HashMap for static data (they could , but virtually no one in those communities is such a glutton for punishment). From Zen of Python: > There shoul…

Forget about DataClasses, TypedDict etc. Can't you achieve the same in python with a class and a dict? Is there a difference, other than perhaps being overloaded with options?

A dataclass will get things like __repr__ for free.

Re: Don't let dicts spoil your code (2020)

#46
post #45

Earlier quoted context omitted.

Forget about DataClasses, TypedDict etc. Can't you achieve the same in python with a class and a dict? Is there a difference, other than perhaps being overloaded with options?

A dataclass will get things like __repr__ for free.

Eq, hash, and init is also "free".

Re: Don't let dicts spoil your code (2020)

#47
post #7

The article is not explaining the point, which I believe is: type your dicts if you want to provide strict guarantees to your downstream about data shape. If you know precisely what the data is used for - great, go ahead - type system is your friend. If you don't know how the data should be used, it's often a different story. Wrapping data in hand typed classes is a terrible idea in the typical data engineering scena…

True. Don't slap in types just because you can — add types when you need to work with your data. Most of the time, I worked with systems where my python code *was* the downstream and required data to run some business logic. In that context, types make the most sense.

Re: Don't let dicts spoil your code (2020)

#48
post #20

When JavaScript added hash/object deconstruction (both at the argument level and assigning variables) I noticed code has been using Dict-like function arguments everywhere. It makes typing them a bit more of a pain in the ass (especially without default arguments). I haven’t decided if I like it better than just breaking up objects into arguments in a more simple functional style. On one hand it’s more predictable bu…

JavaScript doesn't have named arguments, so passing a lot of stuff in arguments makes code unreadable.

Re: Don't let dicts spoil your code (2020)

#49
post #7

The article is not explaining the point, which I believe is: type your dicts if you want to provide strict guarantees to your downstream about data shape. If you know precisely what the data is used for - great, go ahead - type system is your friend. If you don't know how the data should be used, it's often a different story. Wrapping data in hand typed classes is a terrible idea in the typical data engineering scena…

A popular AWS API library does this and it is infuriating. AWS added a new field but the library hasn't been updated yet? Too bad, you can't use that field then!

Re: Don't let dicts spoil your code (2020)

#50
Glad to see pydantic get mentioned here. It’s a great solution for this exact problem. I was introduced to it by FastAPI and have been using it in all my projects since.

At the end of the day you really can’t escape typing. It just makes life easier. We should stop letting languages try to remove it.

Post reply on HN