[bigstrat2003]

For 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.

[Ey7NFZ3P0nzAe]

Personnaly I became a huge fan of beartype : https://pypi.org/project/beartype/

Leyec, the magic dev behind it managed to make a full python type checker with super advanced features and about 0 overhead. It's crazy

[skeledrew]

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 overhead.

[Mattwmaster58]

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.

[skeledrew]

That definitely got implemented after I had already moved on.

[Ey7NFZ3P0nzAe]

Iirc beartype is several orders of magnitude faster than typeguard so you might want to give it a try again

[nerdponx]

Python does typing pretty darn well now for data like API requests and responses.

"Typed Python" does poorly (compared to e.g. Typescript) on things like overloading functions, generics, structural subtyping, et al.

[est]

> 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.

[Aditya_Garg]

Thats only because your list has different types. Its a badly formed API and if you really need to support that use case then you can use maps and reflection to handle it.

[est]

The problem is, programmers can't dictate what JSON should look like in the wild.

We used to have strict typed XML. Nobody even bothered.

[a57721]

> The problem is, programmers can't dictate what JSON should look like in the wild.

Not JSONs in general, but a sane API would never return something like that.

> We used to have strict typed XML. Nobody even bothered.

Nowadays there is OpenAPI, GraphQL, protobuf, etc. and people do bother about such things.

[mook]

Unfortunately, a lot of the time you need to deal with other people's APIs.

[shiroiushi]

>We used to have strict typed XML. Nobody even bothered.

Yeah, because it was ugly as hell and not human-readable.

[emmanueloga_]

gjson [1] and a few other go packages offer a way to parse arbitrary JSON without requiring structs to hold them.

re: Python. I like PyRight/PyLance for Python typing, it seems to "just work" afaict. I also like msgspec for dataclass like behavior [2].

---

1: https://github.com/tidwall/gjson

2: https://jcristharif.com/msgspec/

[jpc0]

[]inferface

But the same issue exists as other dynamic languages, how do you know what the type is of the item you are accessing?

If you know the array will be laid out exactly like that before you make the request you can always create a custom parser to return a struct with those fields name what they actually are instead of arbitrary data.

The only valid way to parse that dynamically is to try and fail in a loop which is inefficient enough that you should stop using whatever API returns that monstrosity.

[Turskarama]

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?

[est]

I can get parsing job easily done without mental gymnastics.

[Turskarama]

Right but what do you do with the parsed object? An array of random objects is used for what, exactly?