python / python/mypy

mypyc silently drops class keyword arguments

Open
#21,938 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug topic-mypyc topic-runtime-semantics
Dominant language
Python
Stars
20.6k
Forks
3.3k
PR merge metrics
PR metrics pending

Description

Bug Report

Keyword arguments given in a class definition line are not forwarded when the
module is compiled. __init_subclass__ is called with no keywords, and a
metaclass is called with none either. Nothing is reported — neither by mypyc
during compilation nor by mypy when type checking.

This is not a case of an unsupported construct being rejected: __init_subclass__
is supported (there is a dedicated py_init_subclass_op in
mypyc/primitives/misc_ops.py), and the docs state that a class using an
unsupported metaclass "is compiled into a regular Python class (non-native
class)". The class is created and the hook does run — only the keywords are
missing, so the resulting behaviour still differs from interpreted Python.

To Reproduce

# repro.py
from typing import Any


class Base:
    def __init_subclass__(cls, **kwargs: Any) -> None:
        print("__init_subclass__ received:", kwargs)


class Child(Base, marker=1):
    pass
$ python -c "import repro"
__init_subclass__ received: {'marker': 1}

$ python -m mypyc repro.py
$ python -c "import repro"
__init_subclass__ received: {}

$ mypy --strict repro.py
Success: no issues found in 1 source file

Expected Behavior

__init_subclass__ (and a metaclass) receives {'marker': 1} in both cases,
as it does in interpreted Python. If forwarding class keywords is out of scope,
mypyc should reject the class rather than compile it and drop them silently.

Actual Behavior

The keywords are dropped. Compilation produces no diagnostic, and the resulting
extension module behaves differently from the same source under the interpreter.

Where this comes from

ClassDef.keywords is populated by the parser (mypy/nodes.py,
mypy/fastparse.py) and used by the checker, but mypyc never reads it —
searching the mypyc package for .keywords returns nothing. The two paths
that create the class both pass positional arguments only:

  • native classes — ClassBuilder.finalize in mypyc/irbuild/classdef.py calls
    py_init_subclass_op with [self.type_obj], and the primitive itself is
    declared with arg_types=[object_rprimitive], so there is no place for
    keywords to go;
  • non-native classes — the metaclass is invoked as
    builder.py_call(non_ext.metaclass, [cls_name, non_ext.bases, non_ext.dict]).

I could not find this limitation mentioned in the mypyc documentation. The
"Native classes" page documents which metaclasses are supported and what
happens to classes that use others, but says nothing about class keywords.

Real-world impact

Libraries that configure classes through class keywords lose that
configuration. With msgspec, whose Struct takes its options this way:

# tags.py
import msgspec


class Fact(msgspec.Struct, frozen=True, tag=True):
    call_id: str
    seq: int
$ python -c "import tags; c = tags.Fact.__struct_config__; print(c.tag, c.frozen)"
Fact True

$ python -m mypyc tags.py
$ python -c "import tags; c = tags.Fact.__struct_config__; print(c.tag, c.frozen)"
None False

$ python -c "
import tags
f = tags.Fact(call_id='c', seq=1)
f.call_id = 'mutated'
print(f)"
Fact(call_id='mutated', seq=1)

frozen=True becomes frozen=False, so instances meant to be immutable can be
mutated. tag=True is lost, so tagged unions stop decoding:

TypeError: If a type union contains multiple Struct types, all Struct types
must be tagged (via `tag` or `tag_field` kwarg)

The tagged-union failure is at least loud. The loss of frozen is not: the code
compiles, passes mypy --strict, and the immutability guarantee simply
disappears at runtime.

@mypy_extensions.mypyc_attr(native_class=False) does not help — the keywords
are dropped either way. Building the struct through a runtime call
(msgspec.defstruct(..., frozen=True, tag=True)) does preserve them, but gives
up static field types.

Your Environment

  • Mypy version used: 2.3.1, and 2.4.0+dev.543dbceea27fc9cca25d8adaaa0b36a77c3e1de8 (same behaviour on both)
  • Mypy command-line flags: python -m mypyc repro.py; type checking with mypy --strict repro.py
  • Mypy configuration options from mypy.ini (and other config files): none
  • Python version used: 3.14.7, reproduced on both the default build and the free-threaded build (3.14.7t)
  • Operating system and version: Linux x86_64, GCC 16.2.1
  • msgspec version (for the second example): 0.21.1

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Run the provided repro.py example under interpreted Python and mypyc, then read ClassBuilder.finalize in mypyc/irbuild/classdef.py and py_init_subclass_op in mypyc/primitives/misc_ops.py. Compare those paths with the non-native builder.py_call path and inspect ClassDef.keywords in mypy/nodes.py and mypy/fastparse.py. Done means class keywords are preserved in both cases, or unsupported cases are rejected instead of silently compiled.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
70/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.