If you want an example of a language where the exact opposite advice is taken at all times (with all the pitfalls described in this blog post), give Clojure a whirl.
Don't let dicts spoil your code
111–120 of 121 posts
Re: Don't let dicts spoil your code
#112Earlier quoted context omitted.
I tried using it, but beartype quickly became a pain with having to decorate things manually. Then I found typeguard which goes even further and never looked back. Instead of manually decorating each individual function, an import hook can be activated that automatically decorates any function with type annotation. Massive QoL improvement. I have it set to only activate during testing though as I'm unsure of the over…
It looks like beartype supports the same sort of implicit decoration, because there's mention of an explicit API: >Beartype now implicitly type-checks all annotated classes, callables, and variable assignments across all submodules of all packages.
That definitely got implemented after I had already moved on.
Re: Don't let dicts spoil your code
#113Earlier quoted context omitted.
TypedDicts "aren't real" in the sense that they're a compile-time feature, so you're getting typing without any deserialization cost beyond the original JSON. Dataclasses and Pydantic models are slow to construct, so that's not nothing. This of course means TypeDicts don't give you run-time validation. For that, and for full-blown custom types in general, I tend to favor msgspec Structs: https://jcristharif.com/msgsp…
> Dataclasses and Pydantic models are slow to construct Citation needed? Pydantic is really quite fast, and you can pass raw JSON responses into it. It may be slower (depending on the validators or structure), but I’d expect it to be comparably fast to the stdlib JSON module.
> Citation needed? Pydantic is really quite fast
Pydantic v1 was slow enough for them to write a lot of the core logic in Rust for Pydantic v2, and for the previous sloth to have been an argument people launched against it if you look back at threads on here and Reddit comparing it to other libraries.
Re: Don't let dicts spoil your code
#114Earlier quoted context omitted.
> Python doesn't do typing well Golang does typing, but JSONs are PITA to handle. Try parsing something like `[{"a': 1, "b": "c", "d": [], "e": {}}, null, 1, "2"]` in go. Types are a bless as well as a curse.
And if you got that JSON back in Python, how would you do anything with it? This API is essentially useless. You can deserisalise it, sure, but then what?
I can get parsing job easily done without mental gymnastics.
Re: Don't let dicts spoil your code
#115Personally I find it is often helpful to keep Dicts in a BigBag ie: BigBag
That's good eating.
Re: Don't let dicts spoil your code
#116I don't agree with the predicate, but I have to admit that the rest of the article is well written to list the different ways to give types to dicts when it is needed.
Re: Don't let dicts spoil your code
#117Earlier quoted context omitted.
And if you got that JSON back in Python, how would you do anything with it? This API is essentially useless. You can deserisalise it, sure, but then what?
I can get parsing job easily done without mental gymnastics.
Right but what do you do with the parsed object? An array of random objects is used for what, exactly?
Re: Don't let dicts spoil your code
#118Earlier quoted context omitted.
If you use type checking, the breakage occurs when you introduce the change: the author of the change is the one who can figure out what it means if 'foo' is no longer being passed into this function. If you're duck typing, you find this out in the best case when your unit tests exercise it, and in the worst case by a support call when that 1/1000 error handling path finally gets exercised in production.
I agree with that, in the context of dynamically typed languages. Slowly but surely, new languages are starting to develop with static duck typing. Implicit interfaces if you will.
Which languages are developing? This is something I’ve been wishing for.
Re: Don't let dicts spoil your code
#119Earlier quoted context omitted.
It looks like beartype supports the same sort of implicit decoration, because there's mention of an explicit API: >Beartype now implicitly type-checks all annotated classes, callables, and variable assignments across all submodules of all packages.
That definitely got implemented after I had already moved on.
Iirc beartype is several orders of magnitude faster than typeguard so you might want to give it a try again
Re: Don't let dicts spoil your code
#120Here’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…
Subclassing NamedTuple is very ergonomic, and given they're immutable unlike data classes I often reach for them by default. I still use Pydantic when I want custom validation or when it ties into another lib like FastAPI.
You know about frozenset, right? Dataclasses can be immutable.
It's python, so take that with a grain of salt.