Giter VIP home page Giter VIP logo

Comments (2)

Fatal1ty avatar Fatal1ty commented on May 28, 2024

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?

from mashumaro.

JWCS avatar JWCS commented on May 28, 2024

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.

from mashumaro.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.