mypyc silently drops class keyword arguments

Abierto
#21,938 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
70/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
compilers

Línea de trabajo

Ejecuta el ejemplo repro.py proporcionado con Python interpretado y mypyc, y después lee ClassBuilder.finalize en mypyc/irbuild/classdef.py y py_init_subclass_op en mypyc/primitives/misc_ops.py. Compara esas rutas con la ruta builder.py_call no nativa e inspecciona ClassDef.keywords en mypy/nodes.py y mypy/fastparse.py. Se considera terminado cuando las palabras clave de clase se conservan en ambos casos, o cuando los casos no compatibles se rechazan en lugar de compilarse silenciosamente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug topic-mypyc topic-runtime-semantics

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
Lenguaje dominante
Python
Estrellas
20.6k
Forks
3.3k
Merge medio
1 d 9 h
PR fusionados (30 d)
56

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de python/mypy

Todos los issues de python/mypy

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.