On 11/29/2012 11:55 PM, Eli Bendersky wrote:
On Sun, Nov 25, 2012 at 9:01 PM, Chris Jerdonek <chris.jerdo...@gmail.com <mailto:chris.jerdo...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
