-
-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How much runtime introspection of types is a good thing? #2687
Comments
In general it means the annotations at runtime are invalid, and can't be evaluated. Anyone passing an affected Trio type or function into a runtime typing library is going to unexpectedly get strange errors. It's also not really possible at all in some cases, like if you wanted to inherit from Additionally, I know Sphinx does runtime introspection for the |
We talked a bit about this on Gitter and my current opinion is that we should allow language/syntax changes (e.g. newer aliases) but not a blunt application of |
While hiding imports being a type-checking guard does improve import speed, in my experience the main reason is to avoid import cycles. I've many times encountered straight up two-way import dependencies A <-> B introduced due to adding type hints, and guarding the imports (or doing very fancy stuff like putting imports at the bottom of the file) has been the best way of resolving them. I also like the distinction in the import list between what's actually needed for the program to run, vs what's just type imports, to get a better sense of what's going on. But I've never used any runtime type checker, so I haven't really encountered the downsides myself. But I could try to default to not hiding anything behind type-checking guards unless it's especially needed though, though at that point I really want #2686 since the import list is going to grow a lot and will be changing frequently. |
If we really do want runtime introspection we could probably get most of the way if we stopped doing from .foo.blah import FooType
def foo(f: FooType):
... and resorted to doing import trio
def foo(f: trio.foo.blah.FooType):
... I'm used to doing the former, but could do the latter if you want runtime introspection. But it'll lead to quite messy and verbose signatures. |
The only possible usecases I can think of for runtime introspection is autodocumenting type hints, or serialisation. I fail to see why you would ever serialise a Trio class. I vote for just using 3.11+ syntax behind |
I think status quo works. We can just continue to allow just as much runtime introspection as Sphinx needs to work nicely. (We've had several PRs where we needed to move something to runtime so that Sphinx could see it!) If anyone does actually need runtime introspection, they can raise an issue with their use case! Genuinely not sure what it could be. If I forgot something, feel free to reopen. |
As I write this, one of the open typing PRs has a function reference a type behind a
if typing.TYPE_CHECKING
branch. This means that the function is not very introspectable.I'm just opening this issue as a quick way to dump thoughts if I get any and to resolve that specific conversation. I don't have solutions and I don't really understand the tradeoffs. Here's the problem as I understand it:
The upsides are:
The downsides are:
See, I don't really understand the downsides. I know that there's use cases related to this but I don't know what or if they're even relevant here!
The text was updated successfully, but these errors were encountered: