Class construction with type() obtains class name, but doesn't interpret __dict__ parameters

[ItsDrike]

When creating a new class using type("MyCls", (), {}), the output is recognized as Type[MyCls], from the first string, however if the passed dict contains some actual parameters/functions, they will not be recognized as being a part of the MyCls function created like this.

Obviously, it's possible to obtain these parameters and their types from the passed dict, but I'm not too surprised it's not being done, since it's probably only categorized as a dict[str, Any] object, rather than a TypedDict, and that's probably not going to change. Although this is a fairly special case and parsing the dict is worth doing, so maybe it could get some sort of custom treatment?

I fully assume this will not be done, but it's an issue and I didn't find references to this being marked as wontfix anywhere (maybe I just haven't looked too hard though), so I'd like to know if there's any chance of it getting into pyright at some point, or if it's a lost cause.

[erictraut]

Yes, pyright doesn't support this form of class creation. It's typically used only for highly dynamic use cases where a static type checker isn't going to work anyway. If your use case doesn't involve dynamic class construction, then you should use the standard class keyword to create a new type, and this will work fine.

class TestCls:
    foo = lambda: None

TestCls.foo

[ItsDrike]

Yeah, standard class creation is fine, though in my case, I need this for unit-tests that require making a bunch of different single-use classes, and it would be pretty annoying to define them with the standard syntax since it would produce a lot of clutter.

Perhaps if the dict is passed directly, pyright could handle that in some special way in comparison to the fully dynamic use-cases where the dict is generated. Though it would be nice to see that being supported too, if the passed dict was a TypedDict. But yeah, this is a pretty niche use-case.

Even if this won't be supported, maybe it should then be treated as Any to avoid these annoying errors with cases like these, since it doesn't make much sense for pyright to identify it as a class with nothing in it, when it doesn't actually know whether that's true or not.

[erictraut]

You can add an Any type annotation for the TestCls symbol if you want it to be treated as such.

I'm reluctant to add special casing here because it would override the type behavior indicated in the builtins.pyi type stub, which is where the type class and its constructor are defined. We've found that when we override the behaviors indicated by the stdlib typeshed stubs, it creates fragility and maintenance problems.

[ItsDrike]

Yeah, that's fair. Thanks for the suggestion of manually adding the type annotation of Any, that's indeed probably the best way to handle it.

Is there even a way for this to be somehow addressed in the builtins stub though? I can't think of any way for this to do that with current python typing, other than maybe just **kwargs: TypedDict.

[erictraut]

The builtins stub could define the __new__ method of the type class to return an Any, but that would have other undesirable side effects. So no, I don't see a good way to handling this in the type stub.

The use case you've described is a pretty extreme edge case. I understand why you might write test code in that manner, although if you are interested in type checking your test code, it's not the approach I would recommend. I think it's reasonable to say that you need to add an explicit Any annotation to accommodate your specific use case.

[greyltc]

It's typically used only for highly dynamic use cases where a static type checker isn't going to work anyway.

I recently ran into this in a mildly dynamic use case where I think having support for type() would actually be useful. I wrote about it here:
microsoft/pylance-release#3317
which now seems like the wrong place, I wish I had found this thread first!