[Python-Dev] type vs. class terminology

[Terry Reedy]

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):
> http://eli.thegreenplace.net/2012/03/30/python-objects-types-classes-and-instances-a-glossary/

> 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 
concrete class.

I might suggest that types are used to reason about programs while 
classes are used to execute programs.

-- 
Terry Jan Reedy