"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | 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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
