[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