Replies: 2 comments 1 reply
-
|
Hi Sebastian, nice meeting you again, it's been a while :) That's actually a pretty good idea with stubs. I was thinking something similar. I think the thing I'm most unsure about is how to enable plugins and what powers to give them as well as how to implement it. Lua? WebAssembly? I don't really have a lot of experience there. |
Beta Was this translation helpful? Give feedback.
-
|
Hi David, nice to be back in contact. I had thought of just running Python code (including extensions), in that way we could just pass python objects (classes, functions) and wouldn't need to define a new API. One thing though that I've been wondering is whether those processors would need to be somehow sandboxed or if we could just trust them. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
This project looks quite promising and I wanted to ask about the future plans, in particular about the plugin support.
I imagine supporting mypy plugins out of the box could be a tough effort, however, I think it could be a good opportunity to work on a proposal similar to PEP 681 (data class transforms) which is more general and could be applied to decorators and classes.
This would be extremely useful as currently it is impossible to type a decorator that adds a keyword argument.
One idea I've been thinking about, is to have a "precompilation" step that generates partial stubs that overrides the types of certain python objects.
For example, if we had a code like:
We could somehow register a stub processor for all
BaseModels, that would accept theMyModelclass and produce a stub. For decorators it's trickier as somehow the stub processor would require to receive the function being wrapped, but the idea is similar one registers a stub processor, that receives the function and outputs a stub.Relevant plugins:
See this ty issue asking to reimplement some popular plugins.
Beta Was this translation helpful? Give feedback.
All reactions