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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4