Fails to flag `None` passed to constructor of `enum.Enum`-based classes

[cstigen]

Bug Report

Mypy fails to flag None passed to constructor of enum.Enum-based classes.

To Reproduce

import enum


class Foo(enum.Enum):
    one = 1


Foo(None)

Note that changing to class Foo(int, enum.Enum) does make mypy flag the error. However, the two aren't equivalent as the latter lets you do Foo.one + 1 while the former requires Foo.one.value + 1.

Edit: In fact, in both forms it fails to flag invalid arguments such as Foo(2). I do realize this is a slightly different case, which is why I'm focusing on None which has different behavior between the two.

Expected Behavior

I would expect mypy to flag the last line as an error:

error: No overload variant of "Foo" matches argument type "None"  [call-overload]

Actual Behavior

Mypy reports no errors.

Your Environment

Tested on

• Mypy 1.13.0 and 1.15.0
• CPython 3.11.10

Used mypy --strict file.py and just mypy file.py.

Contents of mypy.ini (I actually use a pyproject.toml file, but have tested with only this ini-file):

[mypy]
check_untyped_defs = true
disallow_any_generics = false
disallow_incomplete_defs = false
disallow_subclassing_any = false
disallow_untyped_calls = false
disallow_untyped_decorators = true
disallow_untyped_defs = false
enable_error_code = truthy-bool, truthy-iterable
extra_checks = true
ignore_missing_imports = false
local_partial_types = true
no_implicit_optional = true
no_implicit_reexport = false
no_namespace_packages = true
python_version = 3.11
strict_equality = true
warn_redundant_casts = true
warn_return_any = false
warn_unused_configs = true
warn_unused_ignores = true

[sterliakov]

Okay, we just don't check enum constructors, this is not about None but about any incompatible type. Here's the relevant typeshed bit:

mypy/mypy/typeshed/stdlib/enum.pyi

Lines 209 to 214 in 8ed16d1

	# It's not true that `__new__` will accept any argument type,
	# so ideally we'd use `Any` to indicate that the argument type is inexpressible.
	# However, using `Any` causes too many false-positives for those using mypy's `--disallow-any-expr`
	# (see #7752, #2539, mypy/#5788),
	# and in practice using `object` here has the same effect as using `Any`.
	def __new__(cls, value: object) -> Self: ...

I agree this is a nice feature proposal, mypy should be able to refine enum's __new__ to a more specific signature. Maybe even accepting a union of literals in simple cases when enum values are numbers/strings (which are also the most popular, enums with complicated types are much more rare).