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.

Author Takuo Matsuoka
Recipients Takuo Matsuoka
Date 2022-04-05.03:36:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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.)

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.

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)):
    def __prepare__(cls, /, *args, **kwargs):
        return dict(__name__ = cls._name(*args, **kwargs))
    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.


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

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.

The issue was previously

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 same as which I closed
mistaking it with

The issue is different from but seems related to

I haven't figured out the exact relation.

Date User Action Args
2022-04-05 03:36:25Takuo Matsuokasetrecipients: + Takuo Matsuoka
2022-04-05 03:36:25Takuo Matsuokasetmessageid: <>
2022-04-05 03:36:25Takuo Matsuokalinkissue47224 messages
2022-04-05 03:36:25Takuo Matsuokacreate