Issue 759525: inspect.getmembers broken (?) (original) (raw)

Issue759525

Created on 2003-06-23 22:43 by aschmolck, last changed 2022-04-10 16:09 by admin. This issue is now closed.

Messages (4)
msg16588 - (view)	Author: Alexander Schmolck (aschmolck)	Date: 2003-06-23 22:43
inspect.getmembers currently uses `dir` to obtain a list of an object's "members", which omits certain things such as methods of the metaclass, e.g: >>> 'mro' in dict(inspect.getmembers(int)) 0 Since I can't find a description of what exactly constitutes a "member", it is not strictly possible to tell whether this is the intended behavior, but then the documentation should be updated in this case to clarify the semantics more. It currently seems quite hard to answer seemingly innocuous questions such as "What are the methods of class/type X?" with introspection.
msg16589 - (view)	Author: Guido van Rossum (gvanrossum) *	Date: 2003-06-30 15:27
Logged In: YES user_id=6380 This is unclear indeed -- inspect is definitely underspecified. It *is* clearly defined that dir() doesn't return metaclass attributes when the argument is a class. To find out the metaclass arguments, simply use dir(int.__class__). I'll leave this open, but I expect that at best some documentation clarification will come out of this.
msg16590 - (view)	Author: Alexander Schmolck (aschmolck)	Date: 2003-06-30 21:13
Logged In: YES user_id=559641 A documentation clarification seems like a perfectly fine solution to me. I know that I could use ``dir(type(int)`` but the problem I have is not so much that I can't at all find out what I want by introspection, but rather that I often can't do so in a clean and reliable manner that is likely to work in future releases (and dir's doc explicitly states that its behavior can't be relied to stay stable across releases). Currently trying to do metaprogramming in python can sometimes be frustrating, because in the absence of clearly defined semantics for important things it is often a noninutitive (e.g. inspect.ismethod(str.find)) trial-and-error procedure ("oops, that didn't work because it was a ... (new-style class/old-style class/builtin type/class with __slots__/ etc.)") that's unlikely to yield particularly robust solutions. Obviously vagueness allows more leeway for future improvements, but I still think it would be nice if there at least were a uniform and relatively well-defined way to get at an object's attributes and a clarified getmembers could fit the bill.
msg59388 - (view)	Author: Georg Brandl (georg.brandl) *	Date: 2008-01-06 15:48
Added a doc clarification in r59775.