I know how to deal with missing values or variability in maps, and so do a lot of people.. what am I missing here?
Don't let dicts spoil your code
51–60 of 121 posts
Re: Don't let dicts spoil your code
#52Earlier quoted context omitted.
Duck typing is so fragile… Once you have implementations that are depending on your naming or property structure, you can’t update the model without breaking them all. If you use a real type, you never have to worry about this.
You would still have to update everything if you rename a field in a struct, what do you mean you never have to worry?
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.
Re: Don't let dicts spoil your code
#53Earlier quoted context omitted.
If external API adds a new field but your software already worked, you didn't need it in the first place, so why should it matter? Dropping unknown/unused fields makes sense in 99% of cases.
Unfortunately some APIs assume that they will get all the fields as part of the update. If field doesn't exist in the input it gets it will drop the original value during the update.
Re: Don't let dicts spoil your code
#54For better or for worse, Python doesn't do typing well. I don't disagree that I prefer well defined types, but if that is your desire then I think Python is perhaps not the correct choice of language.
> 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.
Re: Don't let dicts spoil your code
#55Earlier quoted context omitted.
Is there any advantage to using a TypedDict for a record over a dataclass?
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…
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.
Re: Don't let dicts spoil your code
#56>"solution : use dataclasses"
Damn, it's almost like using an untyped language for large projects is not a great idea.
Re: Don't let dicts spoil your code
#57It's a bit of an odd article because the second part kind of shows why dicts aren't a problem. You basically just need to apply the most old school of OO doctrines: "recipients of messages are responsible for how they interpret them", and that's exactly what the author advocates when he talks about treating dict data akin to data over the wire, which is correct. If you're programming correctly and take encapsulation…
"Ignore fields coming from the API if you don’t need them. Keep only those that you use."
IMO this addresses only one part of the problem, namely "sanitize your inputs". But if you follow this, and therefore end up with a dict whose keys are known and always the same, using something "struct-like" (dataclasses, attrs, pydantic, ...) is just SO much more ergonomic :)
Re: Don't let dicts spoil your code
#58Can 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?
Here is Rich Hickey with an extreme counter example although I would argue he's really demonstrating against getters and setters. https://www.youtube.com/watch?v=aSEQfqNYNAc
Re: Don't let dicts spoil your code
#59Can 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?
Re: Don't let dicts spoil your code
#60Python 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 "better classes" over traditional classes? How would you choose which of the four (or more?) kinds to use?