Inconsistent behavior with (meta)class arguments

[Viicos]

Asking as a question because I'm not sure if this is by design. Previous history: #6403.

For context, we define ModelMetaclass.__new__() in Pydantic, so even if we could rely on a custom BaseModel.__init_subclass__() to provide type checking for class arguments (which we already do but doesn't seem to be required because ModelMetaclass.__new__() takes priority), we can't lie to type checkers about the existence of ModelMetaclass.__new__(), and so we'd like to confirm support for the the metaclass extra keyword arguments which seems to be inconsistent right now:

Code sample in pyright playground. Seems like mypy also doesn't catch most of these:

from typing import TypedDict, Unpack


# Even though type.__new__()'s signature is:
# def __new__(cls, name: str, bases: tuple[type, ...], namespace: dict[str, Any], /, **kwds: Any)
# I assumed type.__new__() is special-cased by pyright?
class Bare(fail=1): pass  # ✅ No parameter named "fail"



class MetaNoKw(type):
    def __new__(mcls, name, bases, namespace, /) -> type:
        return super().__new__(mcls, name, bases, namespace)

class Model1(metaclass=MetaNoKw): pass

class Sub1(Model1, extra="test"):  # ❌ No error, but will raise at runtime
    pass



class MetaSingleReqKw(type):
    def __new__(mcls, name, bases, namespace, /, keyword: int) -> type:
        return super().__new__(mcls, name, bases, namespace)

class Model2(metaclass=MetaSingleReqKw, keyword=1): pass

class Sub2(Model2):  # ❌ No type check error, but will raise at runtime because `keyword` is missing
    pass

class Sub3(Model2, other=1):  # ❌ No type check error, but will raise at runtime because `keyword` is missing/`other` is unexpected
    pass

class Sub4(Model2, keyword="not_an_int"):  # ❌ No type check error
    pass



class MetaSingleOptKw(type):
    def __new__(mcls, name, bases, namespace, /, keyword: int = 1) -> type:
        return super().__new__(mcls, name, bases, namespace)

class Model3(metaclass=MetaSingleOptKw): pass

class Sub5(Model3, keyword="not_an_int"): pass  # ❌ No type check error




class MetaKwargs(type):
    def __new__(mcls, name, bases, namespace, /, **kwargs: int) -> type:
        return super().__new__(mcls, name, bases, namespace)

class Model4(metaclass=MetaKwargs): pass

class Sub6(Model4, keyword="not_an_int"): pass  # ✅ Argument of type "Literal['not_an_int']" cannot be assigned to parameter of type "int" in function "__new__"



class TD(TypedDict, extra_items=str):
    a: int


class MetaUnpackedKwargs(type):
    def __new__(mcls, name, bases, namespace, /, **kwargs: Unpack[TD]) -> type:
        return super().__new__(mcls, name, bases, namespace)

class Model5(metaclass=MetaUnpackedKwargs, a=1): pass

class Sub7(Model5):  # ✅ Argument missing for parameter "a"
    pass

class Sub8(Model5, a=1, extra=1):  # ✅ Argument of type "Literal[1]" cannot be assigned to parameter of type "str" in function "__new__"
    pass

[erictraut]

Pyright's type checking logic for custom metaclass __new__ methods is incomplete, as your sample shows. Pyright's current implementation does the following:

1. If the class has no custom metaclass or a custom metaclass that does not override type.__new__, it assumes that the class will use type.__new__, which calls through to the __init_subclass__ method. It therefore type checks the argument list provided in the class definition against the __init_subclass__ signature. This explains the behavior with Bare.
2. If the class has a custom metaclass that overrides type.__new__, it performs minimal type checking of the argument list provided in the class definition. In particular, it looks only at keyword-only parameters without defaults and keyword variadic parameters (**kwargs).

I don't recall why the code for case 2 skips positional parameters and keyword parameters with defaults. This is some of the older code in pyright. It's possible that I didn't have a good understanding of the runtime behavior at the time I wrote it. It's also possible that I attempted to implement a more complete check, but it produced too many false positives. I'll note that mypy doesn't appear to check any of these cases.

If you'd like to see more complete type checking for case 2, you're welcome to file an enhancement request in the pyright issue tracker. Unless and until mypy also implements such functionality, I'll consider it a lower priority to support this in pyright.

[Viicos]

Yes, this is understandable. I'm not sure how easy this would be to support in mypy, so I might take a look there first but I have no idea if I'll fully commit to it.

Do you know if I can safely rely on the current pyright behavior (that is, it works when using an unpacked typed dictionary for type.__new__() kwargs), without worrying about this changing in a future pyright version?

[erictraut]

I don't have any plans to change that behavior.