Warn instead of aborting when a class namespace holds a non-string key - #8581

• This PR follows our AI policy

Summary

A class namespace holding a key that is not a string takes the interpreter down:

>>> type("MyClass", (), {1: 2})
thread 'main' panicked at crates/vm/src/builtins/dict.rs:781:65:
dict has non-string keys: [PyObject PyInt { value: 1 }]

CPython builds the class and warns once:

>>> type("MyClass", (), {1: 2})
<stdin>:1: RuntimeWarning: non-string key in the __dict__ of class MyClass
<class '__main__.MyClass'>

A metaclass that writes into the namespace it is given reaches the same line, so class Z(metaclass=M) aborts too when M.__new__ does ns[42] = "x".

A str subclass hit that panic as well, and it names an attribute as well as a str does:

>>> class S(str): pass
...
>>> type("Sub", (), {S("z"): 9}).z
9

_thread.start_new_thread shares the line through its kwargs dict, so it aborted where an ordinary call with the same mapping already raises:

>>> (lambda **k: k)(**{1: 2})
TypeError: keywords must be strings
>>> import _thread
>>> _thread.start_new_thread(lambda: None, (), {1: 2})
thread 'main' panicked at crates/vm/src/builtins/dict.rs:781:65:

The change

Py<PyDict>::to_attributes called expect() on downcast_exact. PyAttributes is an IndexMap keyed by &'static PyStrInterned, so the two kinds of key now split there:

• a str subclass is interned like any other name, through downcast_ref::<PyStr>, which is the test collect_ex_args already applies to keyword names;
• a key that is no kind of string is skipped, and the caller passes a closure that decides what the skip means. type() warns once per class with CPython's wording, _thread raises TypeError: keywords must be strings.

What this does not fix

The key still does not reach the class __dict__, and interning gives up the str subclass:

Either row would mean PyAttributes giving up its interned-string key, which reaches a lot further than the crash does. test_descr.MiscTests.test_type_lookup_mro_reference rests on the first row, because its lookup only reaches MyKey.__eq__ if the key sits in the class dict, so it stays skipped and its reason now names that instead of the crash.

Tests

Lib/test/test_descr.py::test_gh55664 was skipped on this exact panic, quoting it in the reason, and is now unskipped. Without the change the module takes the runner down with it:

0:00:00 load avg: 2.70 [1/1] test_descr

thread 'main' (4629) panicked at crates/vm/src/builtins/dict.rs:781:65:
dict has non-string keys: [PyObject PyInt { value: 1 }]

extra_tests/snippets/builtin_type.py covers the str subclass key, the single warning a class gets however many bad keys it holds, and that warning turning into an exception under simplefilter("error"). It passes under CPython 3.14 too.

Also run: cargo test --workspace --exclude rustpython_wasm --exclude rustpython-venvlauncher --exclude rustpython-capi, cargo test in crates/capi, the extra_tests snippets, cargo fmt --check, the clippy invocation from CI, and -m test over test_descr, test_class, test_type_aliases, test_types, test_thread, test_threading, test_metaclass, test_dict, test_dictviews, test_super, test_abc, test_enum, test_dataclasses, test_functools and test_warnings. The one snippet failure is stdlib_sqlite, which wants a feature that is not in the default set.

Summary by CodeRabbit

• Bug Fixes

  • Class creation now supports attribute keys that are str subclasses.
  • Non-string class dictionary keys remain available in the class dictionary instead of causing a failure.
  • Non-string keyword arguments passed to thread creation now raise a clear TypeError.

• Warnings

  • Class creation emits a RuntimeWarning when non-string attribute keys are encountered.
  • Applications configured to treat warnings as errors can handle this condition consistently.