This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: (closed mistakingly, see the next issue) The variable __module__ in the class body getting an undesirable value from __prepare__ of the metaclass
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.9
process
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: Takuo Matsuoka
Priority: normal Keywords:

Created on 2022-04-05 03:24 by Takuo Matsuoka, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (4)
msg416738 - (view) Author: Takuo Matsuoka (Takuo Matsuoka) Date: 2022-04-05 03:24
Context
-------
Some classes have the variable __name__ in their namespace __dict__ ,
and one may wish to create more such classes with varied values of
__name__ .  Some of those could be created with a metaclass whose
__prepare__ returns a mapping having key "__name__", for which the
value is created depending on the arguments of __prepare__ and can be
updated or deleted in the body of the class to be created.  (See C
below for a very silly example of such a metaclass.)


Problem
-------
The value of __name__ given by __prepare__ becomes not just that in
the class body, but automatically also the value of __module__
there.  As far as I could see, this is not documented, and the
programmer might not notice __module__ was messed up.  I think this
behaviour is unexpected and problematic at least unless a warning is
given on it in the document.


Example
-------
Here's a code which produces a problem.

```
# In this example, the metaclass C is intended to be a class of
# subclasses of:
B = type

class C(type(B)):
    @classmethod
    def __prepare__(cls, /, *args, **kwargs):
        return dict(__name__ = cls._name(*args, **kwargs))
    @classmethod
    def _name(cls, /, *args, **kwargs):
        # The actual value of __name__ doesn't matter much to the
        # issue, so I make this function always return the same silly
        # thing in this example.
        return type.__dict__["__name__"]

class O(B, metaclass=C):
    print(__module__ == __name__) # True
    # Could update or delete __name__ here.
```

Consequently,

>>> O.__module__
<attribute '__name__' of 'type' objects>


Discussion
----------
If the value of __name__ can be read from the scope
outside for the assignment to __module__, then that will erase this
unexpected behaviour and I think it would be a much safer thing to do.


Remarks
-------
The issue was previously

https://bugs.python.org/issue47136

which I'm going to close now since I failed to specify the issue
clearly enough there.  Here I've made the issue more specific.

The issue is different from but seems related to

https://bugs.python.org/issue28869

I haven't figured out the exact relation.


Thanks.
msg416739 - (view) Author: Takuo Matsuoka (Takuo Matsuoka) Date: 2022-04-05 03:26
I'm going to close this one since I failed to specify the issue
clearly enough.  See

https://bugs.python.org/issue47223

for a more specific issue.
msg416740 - (view) Author: Takuo Matsuoka (Takuo Matsuoka) Date: 2022-04-05 03:31
I tried to close

https://bugs.python.org/issue47136

and mistakingly closed this one.

This one is open.  Sorry about the mistake.
msg416742 - (view) Author: Takuo Matsuoka (Takuo Matsuoka) Date: 2022-04-05 03:38
It can't be moved backed to unresolved this way.  I close this one now.
History
Date User Action Args
2022-04-11 14:59:58adminsetgithub: 91379
2022-04-05 03:38:32Takuo Matsuokasetstatus: open -> closed

resolution: duplicate
messages: + msg416742
title: The variable __module__ in the class body getting an undesirable value from __prepare__ of the metaclass -> (closed mistakingly, see the next issue) The variable __module__ in the class body getting an undesirable value from __prepare__ of the metaclass
2022-04-05 03:31:04Takuo Matsuokasetstatus: closed -> open
resolution: duplicate -> (no value)
messages: + msg416740
2022-04-05 03:26:37Takuo Matsuokasetstatus: open -> closed
resolution: duplicate
messages: + msg416739

stage: resolved
2022-04-05 03:24:02Takuo Matsuokacreate