Open JWCS opened 4 months ago
Hi @JWCS
I tried to use both the "new" 3.12 type keyword definition of JSON
The type statement is not yet supported, but this is a good improvement that would be good to include in the next release. It should be trivial.
and the "old" recursive style (avoiding from future import annotations).
Recursion is a problem here. I have not encountered such a case yet, so it has not been tested. It will take more time to figure out if this case can be supported. I'm curious in which real case such a broad recursive type is needed. Could you tell me in more detail about how you are going to use this JSON type?
Thanks for the response. I actually wasn't sure if I was being oblivious in the documentation, and missing this recursive case. I know there's support for custom types... but compared to the lazy solution (below), I was hoping it was me. For recursion, to be honest, I'm pretty heavy with typing, but the only "recursive" definition I've ever seen (of use) is this JSON one, or something that looks like it (read only, int keys, same enough). A solution in the general area of support is likely sufficient (see below).
My real world use case is for dealing with abstract customer json payloads, and validating no (structural) corruption in transmission.
For example, given a bunch of header fields specifying the payload conditions, the payload itself is json; I don't care what the json is, but it is in that format, and I would like to make sure there was no corruption in transmission.
For example, I played with the idea of not serializing the payload, msg: bytes
, leaving it as a bytes stream, not validating the payload's structural integrity, but that's not the actual encoding.
Alternatively, what I am currently doing (the show must move on), is just msg: dict[str, Any]
, which mashumaro happily accepts. And in practice this might be sufficient enough to just be the documented answer. "Just use Any
".
The only downside is that the type then isn't JSON, so there's duplicated type hints. In terms of typechecking, dict[str, Any] > dict[str, JSON]
, which leads to some complaints. But that's not critical; runtime typecheckers test against what's there, which is json, and mypy can be coerced.
Description
In the past, I've used the below JSON type definitions, which have worked well with both static and runtime type checkers (mypy (except the new one, wip) and beartype). I had a message type that included an arbitrary json blob as a field. Attempting to serialize that with mashumaro led to an error. I'm not entirely sure if this recursive functionality is supported by mashumaro, due to pre-compilation, only that the underlying types themselves are. If there's a better workaround, I apologies if I missed the documentation.
What I Did
I tried to use both the "new" 3.12 type keyword definition of JSON, and the "old" recursive style (avoiding
from __future__ import annotations
).