[Python-Dev] type vs. class terminology
tjreedy at udel.edu
Fri Nov 30 21:15:54 CET 2012
On 11/29/2012 11:55 PM, Eli Bendersky wrote:
> On Sun, Nov 25, 2012 at 9:01 PM, Chris Jerdonek
> <chris.jerdonek at gmail.com <mailto:chris.jerdonek at gmail.com>> wrote:
> I would like to know when we should use "class" in the Python 3
> documentation, and when we should use "type." Are these terms
> synonymous in Python 3, and do we have a preference for which to use
> and when?
> I'm sure this has been discussed before. But if this terminology
> issue has already been resolved, the resolution doesn't seem to be
> reflected in the docs. For example, the glossary entries for type and
> class don't reference each other.
> Good question,
> [shameless plug follows, I post this because I truly believe it's very
> relevant to the discussion]
> I had the same doubts some months ago, which led to writing this article
> (relevant to Python 3):
> It examines the class vs. type issue, as well as object vs. instance
You usage seems to me to be stuck in the now mostly useless Python 1
distinction between built-in types and user-defined classes. In Python
3, all instances of type are classes, whether defined with the C or
Python API. Indeed, the existence of a C API to make classes is an
implementation detail, not a language feature. The second parameter of
isinstance or issubclass is a class or set thereof (implemented as a
(homogeneous!) tuple for historical reasons), without distinction of
definition mode. When using an imported class, it mostly does not matter
how the class was defined.
I agree with Guido that it is more useful to use 'class' for the
concrete run-time object and 'type' (except when referring to the object
of that name) for abstract (and static) types. (From this viewpoint,
duck-typing rather than duck-classing *is* the proper term).
Consider the quote from the manual. "An object’s type determines the
operations that the object supports (e.g., “does it have a length?”)."
An object potentially supports len(), and one might say should support
it, if and only if it is a 'finite collection'. That is a 'type' (duck
type) of object, but not a class in the Python sense. Whether an object
actually supports len depends on its run-time class. Similarly, an
object 'should' support sqrt if it is a non-negative scalar number or a
complex number. Square-root-able is also an abstract type, not a
I might suggest that types are used to reason about programs while
classes are used to execute programs.
Terry Jan Reedy
More information about the Python-Dev