Enum and NamedTuple should not allow extra keywords

[sobolevn]

This code produces no error:

from typing import NamedTuple

class A(type): ...

class Foo(NamedTuple, metaclass=A, x=1):
   x: int
   
   
from enum import Enum

class E(Enum, x=1):
    a = 1

It is much easier with the NamedTuple, but, I think that enum might allow some keywords like boundary=STRICT.

So, I think that I will split the PRs for these two problems.

Refs #16432

[erictraut]

Do you happen to know why subclasses of NamedTuple aren't allowed to use a custom metaclass? I don't think NamedTuple itself uses a custom metaclass, so I don't see why there would be a metaclass conflict.

class Foo(NamedTuple):
    x: int
print(type(Foo)) # <class 'type'>

As for Enum, the typeshed stub enum.pyi defines EnumMeta.__new__ as follows:

class EnumMeta(type):
    if sys.version_info >= (3, 11):
        def __new__(
            metacls: type[_typeshed.Self],
            cls: str,
            bases: tuple[type, ...],
            classdict: _EnumDict,
            *,
            boundary: FlagBoundary | None = None,
            _simple: bool = False,
            **kwds: Any,
        ) -> _typeshed.Self: ...
    elif sys.version_info >= (3, 9):
        def __new__(
            metacls: type[_typeshed.Self], cls: str, bases: tuple[type, ...], classdict: _EnumDict, **kwds: Any
        ) -> _typeshed.Self: ...
    else:
        def __new__(metacls: type[_typeshed.Self], cls: str, bases: tuple[type, ...], classdict: _EnumDict) -> _typeshed.Self: ...

The **kwds: Any parameter implies that it accepts arbitrary keyword arguments. Any idea why? Perhaps this is just a bug in typeshed.

[AlexWaygood]

I don't think NamedTuple itself uses a custom metaclass

That's incorrect; it does: https://github.com/python/cpython/blob/1a969b4f55f92a17bec82ce0366021a53afdb2c3/Lib/typing.py#L2715

[erictraut]

Ah, that explains it. Then I'd argue that the typeshed definition of the NamedTuple class should reflect that it has a custom metaclass.

@type_check_only
class _NamedTupleMeta(type): ...

class NamedTuple(tuple[Any, ...], metaclass=_NamedTupleMeta):
    ...

This would more correctly reflect the runtime behavior, and then type checkers wouldn't need to hardcode that knowledge. Their normal metaclass conflict rules would apply.

[AlexWaygood]

Then I'd argue that the typeshed definition of the NamedTuple class should reflect that it has a custom metaclass.

That sounds reasonable to me — though the full semantics of NamedTuple are inexpressible in typeshed's stubs. (At runtime, NamedTuple is a function, not a class — although, unlike nearly all other functions, you can inherit from it, it never appears in a class's __bases__ tuple.) So there's no getting around the fact that NamedTuple will always have to be heavily special-cased by type checkers — this is mostly why we haven't bothered trying to precisely reflect all details of NamedTuple's runtime implementation in typeshed's stubs.

[sobolevn]

This issue has some mypy internal specifics, because we have semanal_enum and semanal_namedtuple, which are a bit different and do not follow the same path as regular classes. Maybe they should (at least for this specific step)?