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

Don't let dicts spoil your code (2020)

roman.pt

Post reply on HN
Print view View original

51–60 of 91 posts

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

#51

Post by oivey »

cerved wrote: post #40
oivey wrote: 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…

Having a proper type system can be immensely powerful. IMHO, duck typing is just adding the burden of type checking to the application layer instead of letting a compiler or linter deal with it. Pythons lack of a good type system is what I miss most

Duck typing is a superset of inheritance. If your language only supports polymorphism via inheritance, then it is strictly less expressive than a language with duck typing.

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

#52

Post by molly0 »

I really liked the structure of this blog post. But It misses the positive aspects of using dictionaries. Like when you are the owner of the api you consume and just want the JSON to flow through your “application tier”

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

#53

Post by fulafel »

snidane wrote: 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…

Another option besides types is using a schema library. You can do more things, like define custom validation rules over eg several fields, publish the schema as data (eg at an API endpint, openapi or json schema etc), reuse it in another language (depending on schema system), version it explicitly, and machine generate it if it comes from some external spec (like a db schema).

Also great for property testing / fuzzing. And other fun meta datamodel stuff like eg inferring schema from example data.

In general programming language type systems are pretty weak in comparison because they're not very programmable. (In most languages, for most people, etc .. there are fancy level type systems approaching formal proof toolkits but they're hard to use)

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

#55

Post by mejutoco »

nicbou wrote: post #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.

Same experience here.

It even has additional advantages, such as generating open api files automatically from the types and validating payloads between microservices.

Pydantic and Typeguard are too very useful libraries in this context.

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

#56

Post by imankulov »

molly0 wrote: post #52

I really liked the structure of this blog post. But It misses the positive aspects of using dictionaries. Like when you are the owner of the api you consume and just want the JSON to flow through your “application tier”

Hey, molly0! Do you have a specific example in mind? I'm thinking about how common this use case could be but can't come up with anything.

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

#57

Post by imankulov »

madsbuch wrote: post #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.

Yes, the context is Python.

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

#58

Post by scotty79 »

I would really like a language where you can swap simple data collections like dicts or arrays with others, better defined, employing better suited algorithms without changing everywhere in your code how you access them.

So if getting a field using simple structure is mycol[key] it should look exacty the same when mycol is no longer a flexible dict containing adhoc objects but complex strongly typed immutanble trie or btree indexed array because at some point of evolution of your code it became apparent that this is exactly what you need.

The only language that I know of that has consistent interface between simple and complex (also custom) collections is Scala.

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

#59

Post by Philip-J-Fry »

scotty79 wrote: post #58

I would really like a language where you can swap simple data collections like dicts or arrays with others, better defined, employing better suited algorithms without changing everywhere in your code how you access them. So if getting a field using simple structure is mycol[key] it should look exacty the same when mycol is no longer a flexible dict containing adhoc objects but complex strongly typed immutanble trie o…

You can do this in any language that has operator overloading, right?

C# or C++ for example.

Or in fact, you can just define an interface with Get/Set methods. Any language with interfaces supports that and you can swap them out as you please.

Doesn't seem like the language is really the restricting factor for implementing this if you really wanted it.

Post reply on HN