Files
RustPython/Lib
Luan Taraschi 782d5d2639 Warn instead of aborting when a class namespace holds a non-string key (#8581)
* Warn instead of aborting when a class namespace holds a non-string key

type() took the whole process down when the namespace it was handed had
a key that was not an exact str:

    >>> 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 }]

to_attributes called expect() on downcast_exact, so a str subclass hit
the same line, and that one names an attribute as well as a str does.
PyAttributes is keyed by interned strings and can hold nothing else, so
a str subclass is now interned like any other name, and a key that is no
kind of string is skipped, with the caller deciding what the skip means.
type() warns once per class, the way CPython does, and
_thread.start_new_thread raises the TypeError an ordinary call already
raises for the same mapping.

The key itself still does not land in the class dict, which is what
test_type_lookup_mro_reference needs, so that one stays skipped with the
reason rewritten.

Assisted-by: Claude Code:claude-opus-5

* Mark test_type_lookup_mro_reference as an expected failure

It aborted the runner before, which is why it was skipped. Now that it
only fails, the run can carry it: five runs in a row report it as an
expected failure, and it cannot turn into a pass while the class dict
drops the key its lookup needs.

Assisted-by: Claude Code:claude-opus-5
2026-08-24 17:52:18 +09:00
..
2026-06-12 11:10:50 +09:00
2026-05-17 20:54:56 +09:00
2026-06-15 11:21:28 +09:00
2026-05-12 00:42:54 +09:00
2026-01-20 15:29:05 +09:00
2026-01-17 19:21:11 +09:00
2026-05-12 20:52:36 +09:00
2026-06-15 11:20:13 +09:00
2026-06-15 11:19:40 +09:00
2026-06-15 11:19:40 +09:00
2026-05-20 23:09:50 +09:00
2025-03-20 14:28:26 +09:00
2025-03-10 11:43:53 +09:00
2026-02-02 01:20:23 +09:00
2025-01-11 18:48:27 +09:00
2025-03-10 11:43:53 +09:00
2025-03-10 23:13:32 -07:00
2026-02-13 13:55:05 +09:00
2026-02-24 01:07:30 +00:00
2026-01-30 19:21:10 +09:00
2026-02-02 01:20:23 +09:00
2026-02-28 12:09:59 +09:00
2026-01-31 10:11:58 +09:00
2025-04-21 20:45:06 -07:00
2026-01-24 00:24:12 +09:00
2026-02-24 01:07:30 +00:00
2026-01-30 16:38:36 +02:00
2026-01-26 10:40:22 +09:00
2026-02-11 16:47:03 +09:00
2025-04-30 14:33:52 +09:00
2026-01-30 07:48:29 +09:00
2026-02-08 16:35:56 +09:00
2026-02-08 16:35:56 +09:00
2026-02-14 21:40:04 +09:00
2026-02-15 21:04:32 +09:00
2026-02-13 14:13:30 +09:00
2026-02-09 12:56:53 +09:00
2026-02-14 18:19:57 +02:00
2026-01-25 00:18:55 +09:00
2026-03-01 14:51:54 +09:00
2026-01-23 23:57:31 +09:00
2026-06-11 13:36:30 +09:00
2026-05-17 19:49:42 +09:00
2026-03-03 20:00:50 +09:00
2026-03-12 18:08:56 +09:00
2026-02-13 20:24:57 +09:00
2026-02-06 01:14:55 +09:00
2026-05-12 20:51:02 +09:00
2025-07-25 10:50:17 +09:00
2026-02-04 18:32:45 +09:00
…
2026-01-21 15:10:40 +09:00
2026-05-12 20:51:46 +09:00
2025-04-21 21:11:42 -07:00
2025-07-17 00:04:12 +09:00
2024-04-26 01:39:02 +09:00
2026-05-12 00:43:34 +09:00
2026-05-12 20:51:57 +09:00
2026-05-13 19:52:56 +09:00
2024-03-22 14:54:02 +09:00
2024-03-22 14:54:02 +09:00
2026-03-01 11:36:46 +09:00
2026-02-14 09:18:09 +09:00
2026-02-11 18:01:41 +09:00
2026-01-21 03:05:05 +09:00
2026-01-30 19:13:59 +02:00
…
2026-05-12 20:53:11 +09:00
2026-01-22 08:02:43 +09:00
2026-03-10 11:28:16 +09:00
2026-03-04 05:38:58 +09:00
2026-06-03 18:36:37 +09:00
2026-06-15 11:20:13 +09:00
2026-06-15 11:20:13 +09:00
2026-06-02 18:00:54 +09:00
2026-02-13 13:42:22 +09:00
2026-01-30 19:21:10 +09:00
2026-03-05 17:25:59 +09:00

Standard Library for RustPython

This directory contains all of the Python files that make up the standard library for RustPython.

Most of these files are copied over from the CPython repository (the 3.7 branch), with slight modifications to allow them to work under RustPython. The current goal is to complete the standard library with as few modifications as possible. Current modifications are just temporary workarounds for bugs/missing feature within the RustPython implementation.

The first big module we are targeting is unittest, so we can leverage the CPython test suite.