[Python-3000] Types and classes

Terry Reedy tjreedy at udel.edu
Thu Apr 3 05:15:15 CEST 2008


"Guido van Rossum" <guido at python.org> wrote in message 
news:ca471dc20804021609j535c54c8h76c5d75ddf992e5a at mail.gmail.com...
| All I really mean to fix is to standardize the terminology,

I have recently been thinking about how to present/explain the basics of 
Python3 to someone with no experience of Python1/2 or any need to know 
about them.  Having one word instead of two to collectively refer to 
objects that have instances would make this easier.  After thinking about 
the posts in this thread, I believe 'classes' slightly wins over 'types'.

| especially in repr().

I think repr(int) == repr(type(0)) == "<class 'int'>"  would be fine.
(Yes, it was jarring at first, but a half hour later, it almost seems 
normal ;-)
The absence of a module name in front of the class name signals that it is 
a builtin class (or writen in C?), for whatever difference that makes.

I do not think having the root metaclass named 'type' is anymore 
problematic than having the base class named 'object'.  That keywords 
cannot be identifiers must be explained and learned anyway.  That 'type' 
doubles as the class-revealer is a matter of economy.

Having repr(type) == "<class 'type'>" might even be clearer than the 
current "<type 'type'>" since 'type' would only appear as a name (of a 
particularly important class) rather than as both a name and a 
metacategory.


I could go with "<type 'socket.socket'>", as the other way of being 
consistent.  But I think 'class' works better both because it is a keyword, 
and not the name of any object, and because it is the word most users use 
to create new classes, even if type(x,y,z) is used internally.

Terry Jan Reedy





More information about the Python-3000 mailing list