Skip to content

Improve metaclass conflict error message with clearer terminology and contextual information #134902

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
AsgerJon opened this issue May 29, 2025 · 2 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@AsgerJon
Copy link

AsgerJon commented May 29, 2025

Feature or enhancement

Proposal:

Improve Metaclass Conflict Error Message

Summary

Improve the error message raised during metaclass conflicts to specify the
base with incompatible metaclass.


Motivation

Class inheritance has a well-established terminology across languages, but
Python's metaclass system introduces a distinct mechanism that lacks clear
linguistic conventions. This feature proposes the following
terminologies.

  • A class is derived from its metaclass
  • A class is based on its base classes
  • A metaclass is any subclass of type

Example

In the following code, MetaFoo and MetaBar are both subclasses of type
making them metaclasses according to the previous terminology suggestion.
Since neither is a subclass of the other, they are incompatible as metaclasses.
Foo derives from MetaFoo and Bar derives from MetaBar, but because
Bar is based on Foo; the conflicting metaclasses cause the TypeError
relating to metaclass conflict.

class MetaFoo(type): pass

class MetaBar(type): pass

class Foo(metaclass=MetaFoo): pass

class Bar(Foo, metaclass=MetaBar): pass  # raises

Current Behaviour

The TypeError currently raised looks like this:

TypeError: metaclass conflict: the metaclass of a derived class must be a
(non-strict) subclass of the metaclasses of all its bases

Proposed Behaviour

The improved error message would add contextual details and adopt the new
terminology: (Line breaks included for clarity).

Metaclass conflict while creating a new class!
- Declared metaclass: 'MetaBar'
- Incompatible base class: 'Foo'
- That base is derived from metaclass: 'MetaFoo'
All base classes must be based on classes derived from the same metaclass or a
subclass thereof.

Notes

This change requires changes to the _PyType_CalculateMetaclass function only.
Including the name (Bar in the example) in the error message would require
changes to multiple functions across the codebase.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

@AsgerJon AsgerJon added the type-feature A feature request or enhancement label May 29, 2025
@ZeroIntensity ZeroIntensity added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label May 30, 2025
@ZeroIntensity
Copy link
Member

As I said in the PR, I'm a little worried about putting newlines in core error messages. I don't think we have precedent for that in many (any?) places, because it can screw up logs and whatnot.

I'd be more comfortable with something like this:

TypeError: metaclass conflict: 'MetaBar' must be a
(non-strict) subclass of the metaclasses of 'Foo' ('MetaFoo').

@AsgerJon
Copy link
Author

AsgerJon commented Jun 3, 2025

As I said in the PR, I'm a little worried about putting newlines in core error messages. I don't think we have precedent for that in many (any?) places, because it can screw up logs and whatnot.

I'd be more comfortable with something like this:

TypeError: metaclass conflict: 'MetaBar' must be a
(non-strict) subclass of the metaclasses of 'Foo' ('MetaFoo').

I have added to the suggestion that line breaks would not be included in the implementation. The aim is clearer terminology.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

2 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy