django-stubs icon indicating copy to clipboard operation
django-stubs copied to clipboard

Add test with 3.14

Open sobolevn opened this issue 2 months ago • 5 comments

sobolevn avatar Oct 09 '25 09:10 sobolevn

@sobolevn Are you planning to take a look at the stubtest failures?

Looks like something changed about builtin enum module __init__, but I haven't investigated.

intgr avatar Oct 13 '25 20:10 intgr

I tried to figure out what's happening with stubtest on Python 3.14

  • error: django.db.models.enums.IntegerChoices.__init__ is inconsistent, runtime does not have parameter "x"
  • error: django.db.models.enums.IntegerChoices.__init__ is inconsistent, runtime does not have parameter "label"
  • error: django.db.models.enums.TextChoices.__init__ is inconsistent, runtime does not have parameter "object"
  • error: django.db.models.enums.TextChoices.__init__ is inconsistent, runtime does not have parameter "label"

error: django.db.models.enums.IntegerChoices.__init__ is inconsistent, runtime does not have parameter "x"
Stub: in file /home/runner/work/django-stubs/django-stubs/django-stubs/db/models/enums.pyi:62
Overload(def (self: django.db.models.enums.IntegerChoices, x: builtins.str | _collections_abc.Buffer | typing.SupportsInt | typing.SupportsIndex), def (self: django.db.models.enums.IntegerChoices, x: builtins.str | _collections_abc.Buffer | typing.SupportsInt | typing.SupportsIndex, label: builtins.str | django.utils.functional._StrPromise))
Inferred signature: def (self: django.db.models.enums.IntegerChoices, x: builtins.str | _collections_abc.Buffer | typing.SupportsInt | typing.SupportsIndex, label: builtins.str | django.utils.functional._StrPromise = ...)
Runtime:
def (self)

error: django.db.models.enums.IntegerChoices.__init__ is inconsistent, runtime does not have parameter "label"
Stub: in file /home/runner/work/django-stubs/django-stubs/django-stubs/db/models/enums.pyi:62
Overload(def (self: django.db.models.enums.IntegerChoices, x: builtins.str | _collections_abc.Buffer | typing.SupportsInt | typing.SupportsIndex), def (self: django.db.models.enums.IntegerChoices, x: builtins.str | _collections_abc.Buffer | typing.SupportsInt | typing.SupportsIndex, label: builtins.str | django.utils.functional._StrPromise))
Inferred signature: def (self: django.db.models.enums.IntegerChoices, x: builtins.str | _collections_abc.Buffer | typing.SupportsInt | typing.SupportsIndex, label: builtins.str | django.utils.functional._StrPromise = ...)
Runtime:
def (self)

error: django.db.models.enums.TextChoices.__init__ is inconsistent, runtime does not have parameter "object"
Stub: in file /home/runner/work/django-stubs/django-stubs/django-stubs/db/models/enums.pyi:78
Overload(def (self: django.db.models.enums.TextChoices, object: builtins.str), def (self: django.db.models.enums.TextChoices, object: builtins.str, label: builtins.str | django.utils.functional._StrPromise))
Inferred signature: def (self: django.db.models.enums.TextChoices, object: builtins.str, label: builtins.str | django.utils.functional._StrPromise = ...)
Runtime:
def (self)

error: django.db.models.enums.TextChoices.__init__ is inconsistent, runtime does not have parameter "label"
Stub: in file /home/runner/work/django-stubs/django-stubs/django-stubs/db/models/enums.pyi:78
Overload(def (self: django.db.models.enums.TextChoices, object: builtins.str), def (self: django.db.models.enums.TextChoices, object: builtins.str, label: builtins.str | django.utils.functional._StrPromise))
Inferred signature: def (self: django.db.models.enums.TextChoices, object: builtins.str, label: builtins.str | django.utils.functional._StrPromise = ...)
Runtime:
def (self)

One aspect is that with Python 3.13 and older, stubtest didn't check these __init__ signatures at all. So stubtest started enforcing somethingi that was previously ignored.

I don't understand, what these __init__ signatures are doing in the first place. I don't think one should be instanciating these classes -- the main API is subclassing API I believe?

They were introduced in pull request #2162 by @Viicos -- maybe you can enlighten what they are doing? Is it some hack for pyright specifically?

I wish there was a way to add conditionals like if CURRENT_TYPE_CHECKER != "mypy": to pyi files.

intgr avatar Nov 16 '25 13:11 intgr

Unfortunately I haven't had a chance to have a look at this yet. Life.

I wish there was a way to add conditionals like if CURRENT_TYPE_CHECKER != "mypy": to pyi files.

I'm pretty sure you can do if not MYPY:?

ngnpope avatar Nov 17 '25 14:11 ngnpope

They were introduced in pull request #2162 by @Viicos -- maybe you can enlighten what they are doing? Is it some hack for pyright specifically?

I can look at this later this week.

Viicos avatar Nov 17 '25 14:11 Viicos

OK, so the if not MYPY hack causes assert_type checks to fail. Is there some plugin magic going on?

Run uv run mypy --strict tests
tests/assert_type/db/models/test_enums.py:292: error: Expression is of type "Any", not "list[tuple[int, _StrPromise]]"  [assert-type]
tests/assert_type/db/models/test_enums.py:292: error: Unable to resolve type of choices property  [misc]
tests/assert_type/db/models/test_enums.py:293: error: Expression is of type "Any", not "list[tuple[int, _StrPromise]]"  [assert-type]
tests/assert_type/db/models/test_enums.py:293: error: Unable to resolve type of choices property  [misc]

intgr avatar Nov 17 '25 20:11 intgr