Raymond Hettinger added the comment: I think this API expansion should not be done.
As a teacher of Python, I find that vars(o) is easily understood as a short-cut for o.__dict__ in much the same way as len(o) is a short-cut for o.__len__(). The proposed change makes this tool harder to teach. The vars() function is often used for more than viewing a dictionary, it is also used in situations where the dictionary can be modified. The proposed feature makes it harder to distinguish cases where it acts like a regular, updateable dict. Further, I believe the addition of invisible magic to vars() will actively promote a misunderstanding of how Python works. When applied to an instance variable, it creates an illusion that a dictionary is present when to whole point of __slots__ is to suppress an instance dictionary. In fact, the actual dictionary entries are the member objects at the class level. This fact would be hidden by the proposed change. In addition it creates confusion by treating __slots__ differently from other class-level descriptor entries such as property objects Another issue is that right now, if a user misspells __slots__ (perhaps as __slots_ por __slot__), the indication that something went wrong is that running vars() on an instance returns a dictionary rather than raising "TypeError: vars() argument must have __dict__ attribute". The proposed change will take away this active affirmation that __slots__ is working and will make debugging more difficult (and it will break any existing __slots__ tests that use assertRaises(TypeError) with vars() to verify that __slots__ is working). Overall, my assessment is that this proposed API expansion impairs the learnabilty and usability of vars(). In the entire long history of vars(), this feature has never been requested. Even the OP said, I just realized that it isn't built-out for inclusion __slots__; rather than saying, I really think this would have helped me with a real debugging problem. We have zero evidence that this proposed feature would be of any value and I have given reasons why it would make the language worse. Guido choose not to include this behavior when he added __slots__ back in Python 2.2 (when many introspection builtins were changed to accommodate new-style classes). IMO, no reason has surfaced in the last 15 years to warrant reversing his decision. ---------- assignee: -> rhettinger _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13290> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
