Skip to content

gh-122634: Deprecate __class_getitem__ on metaclasses#122743

Open
sobolevn wants to merge 2 commits intopython:mainfrom
sobolevn:issue-122634
Open

gh-122634: Deprecate __class_getitem__ on metaclasses#122743
sobolevn wants to merge 2 commits intopython:mainfrom
sobolevn:issue-122634

Conversation

@sobolevn
Copy link
Copy Markdown
Member

@sobolevn sobolevn commented Aug 6, 2024

Copy link
Copy Markdown
Member

@ethanfurman ethanfurman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add a version guard so the test only runs on 3.14 and 3.15, and also add the test (with version guard) that will run on 3.16+.

Copy link
Copy Markdown
Member

@ethanfurman ethanfurman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add a version guard so the test only runs on 3.14 and 3.15, and also add the test (with version guard) that will run on 3.16+.

Can we add a doc-only deprecation warning starting with 3.13?

@sobolevn
Copy link
Copy Markdown
Member Author

sobolevn commented Aug 8, 2024

I would add a version guard so the test only runs on 3.14 and 3.15, and also add the test (with version guard) that will run on 3.16+.

I don't think that this is really needed, we don't do that in other typing-related cases.
I think that it is enough to state when it will be removed and since when it is deprecated.

But, no strong feelings.

Can we add a doc-only deprecation warning starting with 3.13?

I think that this might be a good idea.
Since 3.13 is in rc already, we cannot deprecate the behavior itself.
But, we can state that it will be deprecated in 3.14 (if this is going to be merged first).

Comment thread Doc/whatsnew/3.14.rst Outdated
Comment thread Objects/typeobject.c
res = meta_get(meta_attribute, (PyObject *)type,
(PyObject *)metatype);
Py_DECREF(meta_attribute);
if (res && PyUnicode_EqualToUTF8(name, "__class_getitem__")) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes it so the deprecation gets triggered if you use regular attribute access to access the attribute, but I don't think that's right:

>>> class M(type):
...     def __class_getitem__(*args):
...         return "CGI"
...         
>>> class A(metaclass=M): pass
... 
>>> A.__class_getitem__
<python-input-7>:1: DeprecationWarning: Accessing __class_getitem__ on a metaclass is deprecated since 3.14 and will be removed in 3.16. Instead, define a regular __getitem__ method on a metaclass, if you need this behavior.
  A.__class_getitem__
<bound method M.__class_getitem__ of <class '__main__.M'>>

Instead, the deprecation should trigger only if the lookup is triggered by the subscript operator, like in this example:

>>> A["x"]
<python-input-8>:1: DeprecationWarning: Accessing __class_getitem__ on a metaclass is deprecated since 3.14 and will be removed in 3.16. Instead, define a regular __getitem__ method on a metaclass, if you need this behavior.
  A["x"]
'CGI'

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that there's any clean way to do that. We don't have any info about that in _Py_type_getattro_impl (nor in its public version).

Passing this info would require either a global state or a new parameter in several functions (some of which are public).

Maybe I am missing something?

I don't think that .__class_getitem__ access should really bother us, because:

  1. Users should not access magic method directly
  2. Warning is valid in some cases

@bedevere-app
Copy link
Copy Markdown

bedevere-app Bot commented Aug 14, 2024

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

@github-actions
Copy link
Copy Markdown

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions Bot added the stale Stale PR or inactive for long period of time. label Apr 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting changes stale Stale PR or inactive for long period of time.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants