* Apply only for when parsing I/O. Do not substitute primitives with classes inside your code base for no good reason. Unless validation is needed, prefer a NamedTuple.
Don't let dicts spoil your code (2020)
41–50 of 91 posts
Re: Don't let dicts spoil your code (2020)
#42Maybe 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)
#43People 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)
#44Python'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…
You would probably love Clojure. Perhaps you tried it already?
Re: Don't let dicts spoil your code (2020)
#45Earlier 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?
Re: Don't let dicts spoil your code (2020)
#46Earlier 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.
Re: Don't let dicts spoil your code (2020)
#47The 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…
Re: Don't let dicts spoil your code (2020)
#48When 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…
Re: Don't let dicts spoil your code (2020)
#49The 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…
Re: Don't let dicts spoil your code (2020)
#50At 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.