PyWart (Terminolgy): "Class"

[Rick Johnson]

I have believed for a very long time that "class" was a poor choice of keyword to designate an "object definition".

Firstly, the word /class/ does not transform smoothly into CS from English.NO English definition of "class" comes anywhere close to describing the "structured source code that defines an object". Or even generally as: "something that defines something else". You could try to hammer "classification" into the round hole, but you soon find out it's just a damn square peg!

Secondly, "class" is confusing to newbies. How can someone understand the fundamentals of OOP (which defines objects and interfaces) when they are asked to write classes? (teacher "Okay /class/, we are going to create a new object by writing a class." (student HUH?

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"! It is obvious these people are a victim of their own terminology.

============================================================
Other possible terms include:
============================================================

"subclass":
Since every "user defined object" *must* subclass /something/, using this word would infer such a relationship to the reader. HOWEVER, we would then need to differentiate the general usage of "subclass" (as in: an object that is an extension of another object) from a "user defined subclass" (as in: source code). In any event, "subclass" is a good contender. He's going to the 12th round for sure.

"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.

"object":
This is my favorite word however it does suffer a "verbial" disconnection. What are we suggesting? A single word can be very ambiguous as to intent. However, if we couple the word "object" with the word "define" we then inject intent. "define object" on it's face is perfect! We know everything we need to know. 1) We are defining "something" and 2) that *THAT* "something" is an object! YAY!

Now since "methods" and "functions" (PyWart on these terms coming soon!) require defining, the syntax will now be symmetrical (omitting for now that funcs/meths only use "def"!). However we could drop the "def" and use only "object" to save a few keystrokes and a lot of pyparsing.

I am sure the main arguments against such a clear and logical syntax would be that we would confuse "object definitions" with "real live objects" in normal conversation. But i say that is non-sense because we NEED to be more specific when conversing anyway. Choosing a word like "class" just because we don't want to use two words to refer to "source code that defines an object" (in conversation) is ridiculous. This syntax will inject specificity into our communications and convey meaning more appropriately.

Dear language designers: Stop propagating such foolish terminology! End theinfection of "class" in all source code, docs, and daily conversation. Be more consistent and logical. Resist temptation to use poor terminology simply because other languages have done so before you. Grow a pair already!

 

[Chris Angelico]

Dear language designers: Stop propagating such foolish terminology! End the infection of "class" in all source code, docs, and daily conversation. Be more consistent and logical. Resist temptation to use poor terminology simply because other languages have done so before you. Grow a pair already!

Absolutely. We should learn from Lars Pensjö and start referring to
"blueprint objects" and "clones". Or take the updated version and call
them "programs" and "objects". I'm sure that'll make a huge amount
more sense than using the terms that millions of programmers already
understand.

Alternatively, we could take the Humpty Dumpty approach and assign
meanings to names arbitrarily. But wait till Saturday night when they
come for their wages.

ChrisA

 

[Rick Johnson]

[...]
"object":

This is my favorite word however it does suffer a
"verbial" disconnection. What are we suggesting? A single
word can be very ambiguous as to intent. However, if we
couple the word "object" with the word "define" we then
inject intent. "define object" on it's face is perfect!

I just had an epiphany of sorts.

I really don't like using two words ("define object", or "def obj") and using one single keyword is ambiguous ("object" or "obj"). So the obvious solution is to combine the abbreviated words into one compound keyword that will save keystrokes, save parsing, and all-the-while maintain symmetry. That keyword is "defobj". Coupled with "defmeth" and "deffunc" we now have a symmetrical definition syntax!

deffunc bar():
return

defobj Foo():
defmeth __init__(self, blah):
pass

Extra Credit: Can anyone think of a better solution for defining objects without using keywords at all? Hmm... I'm getting a chubby just thinking about it!

 

[Chris Angelico]

I really don't like using two words ("define object", or "def obj") and using one single keyword is ambiguous ("object" or "obj"). So the obvious solution is to combine the abbreviated words into one compound keyword that will save keystrokes, save parsing, and all-the-while maintain symmetry. That keyword is "defobj". Coupled with "defmeth" and "deffunc" we now have a symmetrical definition syntax!

deffunc bar():
return

defobj Foo():
defmeth __init__(self, blah):
pass

Awesome! Now, just one more step to make Python into the World's Most
Awesome Language(tm): Replace those lengthy words with single symbols
found in the Unicode set; compress everything down and enforce perfect
Unicode handling. Also, demand that names be one character long, to
enforce creativity by the Mark Rosewater principle. We will then have
a truly wonderful language; everything will be so utterly readable.

ChrisA

 

[Tim Chase]

Awesome! Now, just one more step to make Python into the World's Most
Awesome Language(tm): Replace those lengthy words with single symbols
found in the Unicode set; compress everything down and enforce perfect
Unicode handling.

APL will rise to linguistic domination! «maniacal laughter»

-tkc

 

[Steven D'Aprano]

I have believed for a very long time that "class" was a poor choice of
keyword to designate an "object definition".

Firstly, the word /class/ does not transform smoothly into CS from
English. NO English definition of "class" comes anywhere close to
describing the "structured source code that defines an object". Or even
generally as: "something that defines something else".

Your knowledge of English has failed you. Here is the first definition
from Webster's Dictionary (1913 edition):


Class \Class\ (kl[.a]s), n. [F. classe, fr. L. classis class,
collection, fleet; akin to Gr. klh^sis a calling, kalei^n to
call, E. claim, haul.]
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]


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]


"Class" is an excellent ordinary English word to describe what computer
science calls a "class".

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.

Classes are created at runtime, not compile time. They have an id, like
all instances. They have a __class__ attribute, like all instances. They
have a type, like all instances. They *are* instances.

py> class Spam(object):
.... pass
....
py> id(Spam)
168149924
py> isinstance(Spam, type)
True

It is obvious these people are a victim of their own terminology.

You're very funny.

"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__
()

"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
prototype-cased OOP languages like Javascript.


[...]

Now since "methods" and "functions" (PyWart on these terms coming soon!)

Oh I can barely contain my excitement.

 

[Tim Chase]

Your knowledge of English has failed you. Here is the first definition
from Webster's Dictionary (1913 edition):


Class \Class\ (kl[.a]s), n. [F. classe, fr. L. classis class,
collection, fleet; akin to Gr. klh^sis a calling, kalei^n to
call, E. claim, haul.]
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]

Clearly Python should use a keyword like "Kingdom" or "Phylum"
instead. I guess "Kingdom" should be reserved for metaclasses (or
would they be metaphylums? or metaphyla?)

kingdom Baz:
pass

phylum Foo:
__metaphylum__ = Baz

That is SO much clearer ;-)

-tkc

 

[Dennis Lee Bieber]

Awesome! Now, just one more step to make Python into the World's Most
Awesome Language(tm): Replace those lengthy words with single symbols
found in the Unicode set; compress everything down and enforce perfect
Unicode handling. Also, demand that names be one character long, to
enforce creativity by the Mark Rosewater principle. We will then have
a truly wonderful language; everything will be so utterly readable.

<shudder> The offspring of a wild night between LISP and APL?

"World's Most Awesome Language"... World's MAL... "mal" being French
for "sickness"...

 

[Peter]

Real mature lot of responses here guys - shows how much you have grown up.

Reading this thread looked more like observing a bunch of 3rd grader - somebody offers an opinion and all you can do is ridicule it?

Real mature - certainly gives Python a good name having followers like this...

But then I guess I will cop flack for this rejoinder too...

 

[Peter]

Real mature lot of responses here guys - shows how much you have grown up.

Reading this thread looked more like observing a bunch of 3rd grader - somebody offers an opinion and all you can do is ridicule it?

Real mature - certainly gives Python a good name having followers like this...

But then I guess I will cop flack for this rejoinder too...

 

[Tim Delaney]

Oh, and Dennis? Mal. Bad. From the Latin.

I was about to point out the same thing, using the same quote

Tim Delaney

 

[Steven D'Aprano]

Rick Johnson is a well-known troll.

I disagree that Rick is a troll. Trolling requires that the troll makes
statements that he doesn't believe are true, simply in order to get a
response. I do not believe that Rick is doing that. I think he simply has
an imperfect, and poor, understanding of Python design principles,
coupled with astonishingly high levels of arrogance and self-superiority.
Pure Dunning-Kruger effect in action.

http://rationalwiki.org/wiki/Dunning-Kruger_effect


If I believed he was *dishonestly playing dumb to gain reactions*, then I
would not bother to engage with him. But I truly believe that he is not
beyond all hope. His posts on tkinter sometimes demonstrate actual
knowledge. He is clearly articulate and knows more than one programming
language -- although probably not *well*.

But, I must admit, the sheer power of Rick's Reality Denial Field often
defeats me. In frustration I too often killfile him so I don't have to
read his screeds. So I certainly don't blame others who do the same.

Opinion is divided as to the best
way to handle the matter; one school follows the "Don't feed the trolls"
motto and ignores him, the other trolls him right back.

I object to that characterisation. I am not dishonestly making
provocative statements when I engage with Rick.

 

[D'Arcy J.M. Cain]

I disagree that Rick is a troll. Trolling requires that the troll

Doesn't matter. He duck types as one.

 

[Rick Johnson]

]
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'twhat is.

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)
168149924
py> isinstance(Spam, type)
True

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.

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.

A template is certainly not correct for class-based OOP languages like
Python, since it implies *copying*. It might be more appropriate for
prototype-cased OOP languages like Javascript.

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*

 

[alex23]

Doesn't matter.  He duck types as one.

+1

Intent isn't magic. If Rick intends to contribute, he could actually
contribute.

 

[Steven D'Aprano]

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.

Ultimately, everything in Python is "structured text", because the only
way to create a Python program is to write source code. Everything you
say is equally true for every other data type in Python. Floats. Strings.
Ints. Lists. Tuples. Dicts. *Everything*. They are only "structured text"
when they appear in source code, or on the command line, or in the
interactive interpreter, just like classes, and Python then constructs an
object in memory to represent that data structure. Just like classes.

So if you wish to deny that classes are objects, you also have to deny
that lists and strings and ints and floats are objects too.

In Python, either nothing is an object, or everything is an object. There
is no middle ground. You cannot treat classes differently from lists,
because Python treats them the same:

source code of a list literal => list object in memory

source code of a float literal => float object in memory

source code of a class definition => class object in memory

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?

You don't need a class statement ("object definition") to create a class
object. Because classes are instances of the metaclass, there is a
default metaclass (called "type") that does the work of instantiating the
metaclass:


py> name = "Spam"
py> bases = (object,)
py> dict_ = {}
py> thingy = type(name, bases, dict_)
py> isinstance(thingy, type)
True
py> thingy
<class '__main__.Spam'>

Classes are instances of type. That is reality in Python.

Classes are objects just like ints and strings and lists. This is a
fundamental design choice of Python. Deal with it.