datamodel-code-generator VS typing

Like generating pydantic models or dataclasses for an OpenAPI schema? I haven't needed to go in that direction myself, but this[0] looks promising!

Apologies if I've misunderstood your comment

https://koxudaxi.github.io/datamodel-code-generator/

I'm sorry, but you have completely misunderstood the purpose of Open API.

It is not a specification to define your business logic classes and objects -- either client or server side. Its goal is to define the interface of an API, and to provide a single source of truth that requests and responses can be validated against. It contains everything you need to know to make requests to an API; code generation is nice to have (and I use it myself, but mainly on the server side, for routing and validation), but not something required or expected from OpenAPI

For what it's worth, my personal preferred workflow to build an API is as follows:

1. Build the OpenAPI spec first. A smaller spec could easily be done by hand, but I prefer using a design tool like Stoplight [0]; it has the best Web-based OpenAPI (and JSON Schema) editor I have encountered, and integrates with git nearly flawlessly.

2. Use an automated tool to generate the API code implementation. Again, a static generation tool such as datamodel-code-generator [1] (which generates Pydantic models) would suffice, but for Python I prefer the dynamic request routing and validation provided by pyapi-server [2].

3. Finally, I use automated testing tools such as schemathesis [3] to test the implementation against the specification.

[0] https://stoplight.io/

[1] https://koxudaxi.github.io/datamodel-code-generator/

[2] https://pyapi-server.readthedocs.io

[3] https://schemathesis.readthedocs.io

The site also provide a link to the github repo of the underlying program.

Not sure who owns/hosts the site, but its based on this github repo.

That's what datamodel-code-generator propose.

had generally good experience creating typed wrappers for api's with json-schema-to-pydantic[0] converter

[0] https://github.com/koxudaxi/datamodel-code-generator

To save you some work, if you have already an OpenAPI specification at hand, you can use datamodel-code-generator to generate your Pydantic models from the spec.

And there are code generators for it! https://github.com/koxudaxi/datamodel-code-generator/

Iterable[str] is unfortunately evil as it matches str which is often unintended. (see: https://github.com/python/typing/issues/256) One would need both NOT-type and AND-type in order to properly handle these.

The basic motivation behind them is that functions can have arguments that can only take a specific set of values, and those functions return values/types change based on that input. Common examples are (you can find more here):

While yes 26 people liked the idea here: https://github.com/python/typing/issues/193

but looking at relevant issues on GitHub it seems this has been shot down repeatedly. python/typing#18, python/typing#213

See https://github.com/python/typing/issues/256 for a discussion.

Lower bounds are not supported for TypeVars, unfortunately.

Mypy allows that because initial versions of PEP-484 allowed that. This has changed; here's the current wording on the PEP:

> This is no longer the recommended behavior. Type checkers should move towards requiring the optional type to be made explicit.

https://www.python.org/dev/peps/pep-0484/#id29

Dunno, other, larger projects than the one I'm working on seem to run up against this from time to time. (rasa_core, to pick one example from near the top of a Google search; also Telethon, Blender, TensorFlow, Pandas. Guido also filed a bug on the typing module in an early version of Python 3.5 because of unexpected implications of this particular issue, so the problem isn't exactly purely theoretical.) That's aside from the wish for conceptual purity in the call signatures of classes and their subclasses, which is not always and automatically a bad wish to have; and the notion that a language that prides itself on its introspective faculties might want to make introspection of classes from the top of a class hierarchy possible, at least in theory? Perhaps to facility learning about the language and/or visualizing large class hierarchies easily, for instance?