Skip to content

type(...).__name__ is 'EllipsisType' instead of 'ellipsis' #8052

Closed

Description

@myers

Feature

In CPython the type of the ... singleton is named ellipsis (lowercase); types.EllipsisType is just an alias to it. RustPython named the type EllipsisType, so its __name__ and repr disagree with CPython.

Surfaced by running CPython's own stdlib test suite under RustPython — test_json.test_default::test_bad_default fails (its error text embeds type(o).__name__). The minimal standalone reproduction:

Reproduction

print(type(...).__name__)
print(repr(type(...)))

CPython 3.14:

ellipsis
<class 'ellipsis'>

RustPython:

EllipsisType
<class 'EllipsisType'>

(types.EllipsisType is type(...) is True on both — only the name differs. A user-visible consequence: the json encoder's PEP 678 note when serializing {type(o).__name__} object reads EllipsisType instead of ellipsis.)

Python Documentation or reference to CPython source code

  • types.EllipsisType — documented as the type of Ellipsis; its __name__ is ellipsis.
  • CPython's PyEllipsis_Type has tp_name = "ellipsis".
  • RustPython's PyEllipsis is declared #[pyclass(module = false, name = "EllipsisType")]; that name is the type's tp_name.

Suggested fix

Rename the pyclass name to "ellipsis". types.EllipsisType still resolves (it is defined as an alias), and now reports __name__ == 'ellipsis', so the test_bad_default failure above then passes.


Investigated and drafted with AI assistance (Claude Code), reviewed by a human before filing, per RustPython's AI policy.

Activity

  1. added
    C-compatA discrepancy between RustPython and CPython
    on Jun 5, 2026
  2. fanninpm commented on Jun 5, 2026

    @fanninpm
    Contributor

    What tests would fail when EllipsisType is absent?

  3. myers commented on Jun 5, 2026

    @myers
    Author

    @fanninpm

    What tests would fail when EllipsisType is absent?

    I think I updated the description after the first post with that info: test_json.test_default::test_bad_default

  4. fanninpm commented on Jun 5, 2026

    @fanninpm
    Contributor

    I think I misunderstood the first time. To be clear, EllipsisType is supposed to be defined in Lib/types.py and nowhere else, correct?

  5. myers commented on Jun 7, 2026

    @myers
    Author

    Let me lay out exactly where each piece lives, since "defined" splits into two things — the type vs. the EllipsisType name — and RustPython mirrors CPython here.

    The type itself (whose __name__/tp_name is "ellipsis", lowercase):

    • CPython: Objects/sliceobject.c — PyEllipsis_Type, tp_name = "ellipsis".
    • RustPython: crates/vm/src/builtins/slice.rs — #[pyclass(... name = "EllipsisType")]. This name is the bug — it should be "ellipsis".

    The EllipsisType name is never a type — it's just an alias to that type, exposed by the types module. On both interpreters Lib/types.py does from _types import * first, with a pure-Python fallback:

    • CPython: the C module Modules/_typesmodule.c provides EllipsisType; fallback is EllipsisType = type(Ellipsis) in Lib/types.py.
    • RustPython: the native module crates/vm/src/stdlib/_types.rs provides EllipsisType (→ ctx.types.ellipsis_type); same type(Ellipsis) fallback in Lib/types.py.
    • Lib/_collections_abc.py also binds EllipsisType = type(...) — on both, for internal use.

    So to your question: no, it isn't "in types.py and nowhere else" — but every occurrence is an alias computed from the object (type(Ellipsis) / ctx.types.ellipsis_type), not a lookup of the type's name. That's why the fix is just renaming the builtin's name to "ellipsis": types.EllipsisType is type(...) stays True everywhere, and only name/repr change — to match CPython.

  6. shAn-kor commented on Jul 6, 2026

    @shAn-kor
    Contributor

    I’m interested in working on this issue. Is it okay if I take it?

  7. myers commented on Jul 10, 2026

    @myers
    Author

    @shAn-kor I was trying to follow the https://github.com/RustPython/.github/blob/main/AI_POLICY.md. I have a backlog of AI found and fixed changes as I was attempting to get django to work on RustPython. I picked the simplest to put up as an issue. I have a fix, just waiting for this to be "approved".

  8. shAn-kor commented on Jul 11, 2026

    @shAn-kor
    Contributor

    @shAn-kor I was trying to follow the https://github.com/RustPython/.github/blob/main/AI_POLICY.md. I have a backlog of AI found and fixed changes as I was attempting to get django to work on RustPython. I picked the simplest to put up as an issue. I have a fix, just waiting for this to be "approved".

    Thanks for letting me know.

  9. youknowone commented on Aug 11, 2026

    @youknowone
    Member

    @myers I removed the allowlist policy from AI policy. I am sorry to hold you from submitting patches. Could you please submit one now? Thanks!

  10. youknowone commented on Oct 6, 2026

    @youknowone
    Member

    The originally reported problem no longer reproduces on current main. Closing per the recheck in #8982.

    — commented by Grok 4.6

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

Metadata

Metadata

Assignees

Labels

C-compatA discrepancy between RustPython and CPython

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions