PyWart (Terminolgy): "Class"
rantingrickjohnson at gmail.com
Tue Jan 15 07:54:10 CET 2013
On Monday, January 14, 2013 11:26:37 AM UTC-6, Steven D'Aprano wrote:
> On Sun, 13 Jan 2013 22:46:44 -0800, Rick Johnson wrote:
> Your knowledge of English has failed you. Here is the first definition
> from Webster's Dictionary (1913 edition):
> Class [...]
> 1. A group of individuals ranked together as possessing
> common characteristics; as, the different classes of
> society; the educated class; the lower classes.
> [1913 Webster]
This is a poor definition for an object. I would rather apply this definition to a collection of objects than to the definition of a single object. Remember, we want to choose a word that is "self documenting".
> And definitions 3 and 4:
> 3. A comprehensive division of animate or inanimate objects,
> grouped together on account of their common
> characteristics, in any classification in natural science,
> and subdivided into orders, families, tribes, genera, etc.
> [1913 Webster]
> 4. A set; a kind or description, species or variety.
> [1913 Webster]
But again, neither of these definitions describe what an object is, in fact, "class" creates a cognitive disconnect between "object definitions" and "objects". "Class" is only concerned with grouping, characteristics, or comparisons.
And let's not forget the obvious. When we are defining "objects" we are wielding a paradigm called "Object Oriented Programming". Only a fool would choose something besides "object" as a keyword.
> "Class" is an excellent ordinary English word to describe what computer
> science calls a "class".
Well if that statement is not a fine example of circular reasoning, i don't what is. o_O
> > Thirdly, once people *DO* understand that a "class" is simply an "object
> > definition", they still go on to say idiotic things like: "Classes are
> > objects"!
> Your knowledge of Python has failed you.
> Classes are objects in Python, although not in all other languages.
Python "classes" are OBJECT DEFINITIONS, not OBJECTS!
> Classes are created at runtime, not compile time.
No, classes DO NOT exist at runtime OR compile time! Classes are only *structured text* (or code if you prefer) that instruct Python to build *real* MEMORY OBJECTS for us. The "magic" that you are witnessing is Python, not classes. Would you argue as intently that the fictional characters of LOTR are real? They could be considered real in your imagination, but without a mind to interpret these characters they will be nothing more than text on a page. Same goes for classes.
> They [classes] have an id, like
> all instances. They have a __class__ attribute, like all instances. They
> have a type, like all instances. They *are* instances.
Replace "class" with object and you will be correct.
> py> class Spam(object):
> ... pass
> py> id(Spam)
> py> isinstance(Spam, type)
Do you understand that your object definition named "Spam" is transformed into a memory object by python and that the id() function and the isinstance() function are operating on a memory object and not your structured text? Stop fooling around Steven, really.
> > "subclass":
> > Since every "user defined object" *must* subclass /something/,
> Only in Python 3. In Python 2, some classes are not subclasses.
> py> class OldStyleClass:
> ... pass
> py> OldStyleClass.__bases__
Ignoring the fact that this comment has nothing to do with the main argument and is in fact an attempt to distract the audience from your downward spiral of circular reasoning... "OldStyleClasses are a direct result of GvR and his anti OOP (anti functional also) programming mentality and lend no weight to your argument. Gudio was wrong to allow classes to be defined without deriving from /something/. He wisely removed old style classes in Python3000. They don't exist in Python's future. Let them rest in peace.
> > "template":
> > This term is very close, but still lacking a concrete relationship
> > between source code (definition of object) and the resulting "thing"
> > living in memory (object). I think this one is TKO in round 3.
> A template is certainly not correct for class-based OOP languages like
> Python, since it implies *copying*. It might be more appropriate for
Agreed. I never really liked the term anyway, but i needed one more choice to round out my list of candidates. Think of "template" as the ugly friend the average girl brings to the bar to make herself seem prettier by comparison. *wink*
More information about the Python-list