You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
.isclass: says "Return true if the object is a class." Since the issue
of builtin versus Python coded is involved in all the other methods
below, I would expand this to
"Return true if the object is a class, whether built-in or Python-coded."
to emphasize that this is not an issue for this one.
.isfunction: current "Return true if the object is a Python function or
unnamed (lambda) function." falsely implies that there is such a thing
as 'unnamed (lambda) function; different from 'Python function'. By
test, it just returns True for 'function' objects. Suggestion:
"Return true for Python-coded functions, including unbound Python-coded
methods." or possibly
"Return true for functions created by def statements and lambda
expressions, including unbound Python-coded methods.
.ismethod: "Return true if the object is a method." should be specified
to something like
"Return true if the object is a bound method written in Python."
.isbuiltin: says "Return true if the object is a built-in function."
but actually tests for membership in class 'builtin_function_or_method'.
I believe that truth is
"Return true if the object is a built-in function (but not a class) or a
bound built-in non-special method."
It is True, for instance, for [].append but not [].__hash__. I am
assuming that this behavior is intended and not a bug.
.ismethoddescriptor: "Return true if the object is a method descriptor,
but not if ismethod() or isclass() or isfunction() are true." begs the
question of what a method descriptor is. I believe the following is
both true and clearer.
"Return true if the object is a built-in method and isbuiltin() is false.
I would follow with
"The methods isclass, isfunction, ismethod, isbuiltin, and
ismethoddescriptor are mutually exclusive."
I believe the following is true, and could be added also.
"Exact one is true for any instance of a built-in callable class."
Activity
terryjreedy commentedon Jan 17, 2009
inspect module in 3.0
.isclass: says "Return true if the object is a class." Since the issue
of builtin versus Python coded is involved in all the other methods
below, I would expand this to
"Return true if the object is a class, whether built-in or Python-coded."
to emphasize that this is not an issue for this one.
.isfunction: current "Return true if the object is a Python function or
unnamed (lambda) function." falsely implies that there is such a thing
as 'unnamed (lambda) function; different from 'Python function'. By
test, it just returns True for 'function' objects. Suggestion:
"Return true for Python-coded functions, including unbound Python-coded
methods." or possibly
"Return true for functions created by def statements and lambda
expressions, including unbound Python-coded methods.
.ismethod: "Return true if the object is a method." should be specified
to something like
"Return true if the object is a bound method written in Python."
.isbuiltin: says "Return true if the object is a built-in function."
but actually tests for membership in class 'builtin_function_or_method'.
I believe that truth is
"Return true if the object is a built-in function (but not a class) or a
bound built-in non-special method."
It is True, for instance, for [].append but not [].__hash__. I am
assuming that this behavior is intended and not a bug.
.ismethoddescriptor: "Return true if the object is a method descriptor,
but not if ismethod() or isclass() or isfunction() are true." begs the
question of what a method descriptor is. I believe the following is
both true and clearer.
"Return true if the object is a built-in method and isbuiltin() is false.
I would follow with
"The methods isclass, isfunction, ismethod, isbuiltin, and
ismethoddescriptor are mutually exclusive."
I believe the following is true, and could be added also.
"Exact one is true for any instance of a built-in callable class."
BreamoreBoy commentedon Jul 4, 2010
Has this issue simply slipped under the radar?
birkenfeld commentedon Jul 11, 2010
No, I've just had no time to review the suggested changes.
birkenfeld commentedon Oct 15, 2010
Committed suggestions with a few changes in r85541.