[issue47136] The variable __module__ in the class body getting an undesirable value from __prepare__ of the metaclass
Takuo Matsuoka added the comment:
Thank you Ethan for your comments.
Sure, I was not familiar with how you measure the magnitude of the
consequences. The code in my own work was of the kind of the generic
example I gave, but I have abandoned the approach, and don't seem able
to find it any more. I think the approach turned out not ideal for
the specific aim I had, which I'm sorry I can't recall now.
I might just say there may be circumstances where a not so thoughtful
programmer might get inclined to implementing a metaclass C in some
manner like:
```
class C(type(B)):
# Skip __init__ . It's just to help checking type later.
def __init__(self, /, *args, **kwargs):
super().__init__(*args, **kwargs)
dict_ = self.__dict__
try:
name = dict_["__name__"]
except KeyError:
pass
else:
name._owner = self
@classmethod
def __prepare__(cls, /, *args, **kwargs):
return dict(__name__ = cls._name(*args, **kwargs))
@classmethod
class _name:
def __get__(self, instance, owner=None):
if instance is None:
if issubclass(owner, self_owner := self._owner):
return self
else:
raise TypeError(f'{owner} is not a subclass of'
f' {self_owner.__qualname__}')
name = instance._super().__name__ # See the class O
# below.
#
#
# Any procedure here, depending on what you'd like to do
# with the instance of your class...
#
return name
def __init__(self, cls, /, *args, **kwargs): ..
def __set__(self, instance, value): ..
def __delete__(self, instance): ..
```
where she creates instances of the metaclass C by inheriting from:
```
class O(B, metaclass=C):
def _super(self):
return super()
def __init_subclass__(cls, /, *args, **kwargs):
return super().__init_subclass__(*args)
```
Another thing I can say is code that does something like that is not
what I write often or even had written before, I guess. Still, I
reported the issue thinking some people (possibly including myself)
may come around the kind of code some time in the future again.
If the behaviour is not going to be changed, then I think the
documentation should at least be made sure to warn about it. I don't
think the behaviour can be expected without documentation.
Thanks.
--
___
Python tracker
<https://bugs.python.org/issue47136>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47136] The variable __module__ in the class body getting an undesirable value from __prepare__ of the metaclass
Takuo Matsuoka added the comment: Thank you Ethan for reopening this issue and closing the other one. Here is a description of a more specific issue, containing a more reasonable example. I've changed the title of the issue to a more appropriate one accordingly. 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. Also, the problem means we can't safely enjoy the ability of __prepare__ of a metaclass to give a candidate for the value of __name__ in __dict__ of the class without the trouble of fixing the variable __module__ later at the top of the class body for every instance of the metaclass (very annoying) somehow (or in __new__ or __init__ of the metaclass if __module__ is not to be read in the class body). 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__ Thanks. P.S. The argument mentioning "the scope outside" in my earlier post here didn't make sense without specifying which scope. I still hope the problem can be fixed. -- title: Wrong value assigned automatically to the variable __module__ in the class body. -> The variable __module__ in the class body getting an undesirable value from __prepare__ of the metaclass ___ Python tracker <https://bugs.python.org/issue47136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47136] Wrong value assigned automatically to the variable __module__ in the class body.
Takuo Matsuoka added the comment: I'm going to close this one since I failed to specify the issue clearly enough. See https://bugs.python.org/issue47224 for a more specific issue. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47223] (closed mistakingly, see the next issue) The variable __module__ in the class body getting an undesirable value from __prepare__ of the metaclass
Takuo Matsuoka added the comment: It can't be moved backed to unresolved this way. I close this one now. -- resolution: -> duplicate status: open -> closed 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 ___ Python tracker <https://bugs.python.org/issue47223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47224] The variable __module__ in the class body getting an undesirable value from __prepare__ of the metaclass
New submission from Takuo Matsuoka : 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__ 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 same as https://bugs.python.org/issue47223 which I closed mistaking it with https://bugs.python.org/issue47136) The issue is different from but seems related to https://bugs.python.org/issue28869 I haven't figured out the exact relation. Thanks. -- components: Interpreter Core messages: 416741 nosy: Takuo Matsuoka priority: normal severity: normal status: open title: The variable __module__ in the class body getting an undesirable value from __prepare__ of the metaclass type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue47224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47223] The variable __module__ in the class body getting an undesirable value from __prepare__ of the metaclass
Takuo Matsuoka added the comment: I tried to close https://bugs.python.org/issue47136 and mistakingly closed this one. This one is open. Sorry about the mistake. -- resolution: duplicate -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue47223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47223] The variable __module__ in the class body getting an undesirable value from __prepare__ of the metaclass
Takuo Matsuoka added the comment: 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. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47223] The variable __module__ in the class body getting an undesirable value from __prepare__ of the metaclass
New submission from Takuo Matsuoka : 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__ 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. -- components: Interpreter Core messages: 416738 nosy: Takuo Matsuoka priority: normal severity: normal status: open title: The variable __module__ in the class body getting an undesirable value from __prepare__ of the metaclass type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue47223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47136] Wrong value assigned automatically to the variable __module__ in the class body.
Takuo Matsuoka added the comment: Thank you for your response. I think __name__ here is very different from __len__ . (1) Even if you set __name__ to what should be the right value, e.g., when my class O will be a subclass of say 'type', and __name__ is an appropriate thing for your purposes to override the attribute '__name__' of 'type' objects (held as the entry '__name__' of type.__dict__), the same value is going to be O.__dict__["__module__"] as long as you let __prepare__ of the mataclass C provide it. (2) Even if, in other cases, you do del __name__ at the end of the body of the class O, the problem remains unless you know O.__dict__["__module__"] will be changed anyway. The behaviour is not documented as far as I could see. I think such a behaviour is problematic if it can't be expected from what's documented. If the value of __name__ can be read from the scope outside, then that will erase this unexpected behaviour and I think it would be a much safer thing to do. Thanks. -- ___ Python tracker <https://bugs.python.org/issue47136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47136] Wrong value assigned automatically to the variable __module__ in the class body.
New submission from Takuo Matsuoka : In the creation of a class, it looks as if the value of the variable __name__ gets assigned automatically to the variable __module__ in the class body. However, the correct name space where the value of __name__ should be looked up is NOT the mapping object returned by the method __prepare__ of the metaclass. In the class body, the programmer may use the variable __name__ for some other purposes, and might not notice __module__ was messed up. Here's a code which produces a problem. ``` class C(type): @classmethod def __prepare__(cls, /, *args, **kwargs): return dict(__name__ = "whatever") class O(metaclass=C): print(__module__) # "whatever" printed ``` Consequently, >>> O.__module__ 'whatever' The issue is different from but seems related to https://bugs.python.org/issue28869 I haven't figured out the exact relation. Thanks. -- components: Interpreter Core messages: 416118 nosy: Takuo Matsuoka priority: normal severity: normal status: open title: Wrong value assigned automatically to the variable __module__ in the class body. type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue47136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44983] Wrong definition of a starred expression in the Language Reference
Takuo Matsuoka added the comment: Thanks Éric Araujo, for the information. Actually, I sought for a similar issue here in the tracker, but didn't find one filed, so this report appears to be unique. -- ___ Python tracker <https://bugs.python.org/issue44983> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45015] Language Reference failing to describe the treatment of starred expressions
New submission from Takuo Matsuoka : The issue is described as Issue (1) here: https://mail.python.org/archives/list/python-id...@python.org/message/BEGGQEU6MG7RYIY7HB4I6VQ23L6TXB6H/ Please look at "Note" just before "Issues treated" there as well. What's mentioned in this note is also filed in this issue tracker with ID 44983 https://bugs.python.org/issue44983 Coming back to Issue (1), the discrepancy is in the definitions of yield_expression, return_stmt, augmented_assignment_stmt, and for_stmt. (That is, the only exception is the definition of subscription https://docs.python.org/3/reference/expressions.html#subscriptions making the exception look inconsistent and confusing.) https://docs.python.org/3/reference/expressions.html#yield-expressions https://docs.python.org/3/reference/simple_stmts.html#the-return-statement https://docs.python.org/3/reference/simple_stmts.html#augmented-assignment-statements https://docs.python.org/3/reference/compound_stmts.html#the-for-statement (In case someone is interested in what are proposed over there, a summary of the proposal can also be found at https://mail.python.org/archives/list/python-id...@python.org/message/KF37FMD5K5M2ZVTJO6IS3J6M7HHE4VRU/ ) -- assignee: docs@python components: Documentation messages: 400346 nosy: Takuo Matsuoka, docs@python priority: normal severity: normal status: open title: Language Reference failing to describe the treatment of starred expressions versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45014] SyntaxError describing the error using a wrong term
New submission from Takuo Matsuoka : The error is this: >>> *() File "", line 1 SyntaxError: can't use starred expression here I think it's right SyntaxError is raised here, but the message is incorrect. Indeed, many starred expressions are actually allowed there. E.g., >>> *(), () I happen to have filed in this issue tracker the problem that the definition of a starred expression given in the Language Reference is incorrect. https://bugs.python.org/issue44983 It appears all correct starred expressions and only them are allowed at the point of the error. Thus the error appears to be one because "*()" is not a starred expression in the correct sense. I think the wording in the message should be corrected. -- components: Interpreter Core messages: 400344 nosy: Takuo Matsuoka priority: normal severity: normal status: open title: SyntaxError describing the error using a wrong term type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44983] Wrong definition of a starred expression in the Language Reference
New submission from Takuo Matsuoka : Being unaware of the processes here, I have posted the issue to the python-idea mailing list. Please refer to it. https://mail.python.org/archives/list/python-id...@python.org/message/TCWYZIIRZWIR7CDJWDAUBCAMU2CBFB3Y/ Thank you. -- assignee: docs@python components: Documentation messages: 400136 nosy: Takuo Matsuoka, docs@python priority: normal severity: normal status: open title: Wrong definition of a starred expression in the Language Reference type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44983> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
