Skip to content

Conversation

@sobolevn
Copy link
Member

@sobolevn sobolevn commented Oct 9, 2025

No description provided.

@intgr
Copy link
Collaborator

intgr commented Oct 13, 2025

@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
Copy link
Collaborator

intgr commented Nov 16, 2025

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 intgr self-assigned this Nov 16, 2025
@ngnpope
Copy link
Member

ngnpope commented Nov 17, 2025

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:?

@Viicos
Copy link
Contributor

Viicos commented Nov 17, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

5 participants