PyWart (Terminolgy): "Class"

Discussion in 'Python' started by Rick Johnson, Jan 14, 2013.

  1. Rick Johnson

    Rick Johnson Guest

    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!
     
    Rick Johnson, Jan 14, 2013
    #1
    1. Advertising

  2. On Mon, Jan 14, 2013 at 5:46 PM, Rick Johnson
    <> wrote:
    > 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
     
    Chris Angelico, Jan 14, 2013
    #2
    1. Advertising

  3. Rick Johnson

    Rick Johnson Guest

    On Monday 1-14-2013 at 12:46 AM, Rick Johnson wrote:
    > [...]
    > "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!
     
    Rick Johnson, Jan 14, 2013
    #3
  4. On Mon, Jan 14, 2013 at 6:32 PM, Rick Johnson
    <> wrote:
    > 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
     
    Chris Angelico, Jan 14, 2013
    #4
  5. Rick Johnson

    Tim Chase Guest

    On 01/14/13 01:56, Chris Angelico wrote:
    > On Mon, Jan 14, 2013 at 6:32 PM, Rick Johnson
    > <> wrote:
    >> 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.


    APL will rise to linguistic domination! «maniacal laughter»

    -tkc
     
    Tim Chase, Jan 14, 2013
    #5
  6. On Sun, 13 Jan 2013 22:46:44 -0800, Rick Johnson wrote:

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


    --
    Steven
     
    Steven D'Aprano, Jan 14, 2013
    #6
  7. Rick Johnson

    Tim Chase Guest

    On 01/14/13 11:26, Steven D'Aprano wrote:
    > 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
     
    Tim Chase, Jan 14, 2013
    #7
  8. On Mon, 14 Jan 2013 18:56:08 +1100, Chris Angelico <>
    declaimed the following in gmane.comp.python.general:

    > 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"...
    --
    Wulfraed Dennis Lee Bieber AF6VN
    HTTP://wlfraed.home.netcom.com/
     
    Dennis Lee Bieber, Jan 14, 2013
    #8
  9. Rick Johnson

    Peter Guest

    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, Jan 14, 2013
    #9
  10. Rick Johnson

    Peter Guest

    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, Jan 14, 2013
    #10
  11. Rick Johnson

    Tim Delaney Guest

    On 15 January 2013 07:57, Chris Angelico <> wrote:

    >
    > Oh, and Dennis? Mal. Bad. From the Latin. :)
    >


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

    Tim Delaney
     
    Tim Delaney, Jan 14, 2013
    #11
  12. On Tue, 15 Jan 2013 07:57:58 +1100, Chris Angelico wrote:

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


    --
    Steven
     
    Steven D'Aprano, Jan 15, 2013
    #12
  13. On 15 Jan 2013 02:08:38 GMT
    Steven D'Aprano <> wrote:
    > > Rick Johnson is a well-known troll.

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


    Doesn't matter. He duck types as one.

    --
    D'Arcy J.M. Cain <> | Democracy is three wolves
    http://www.druid.net/darcy/ | and a sheep voting on
    +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
    IM:
     
    D'Arcy J.M. Cain, Jan 15, 2013
    #13
  14. Rick Johnson

    Rick Johnson Guest

    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'twhat 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)
    > 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.

    > > "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
    > 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*
     
    Rick Johnson, Jan 15, 2013
    #14
  15. Rick Johnson

    alex23 Guest

    On Jan 15, 1:28 pm, "D'Arcy J.M. Cain" <> wrote:
    > Steven D'Aprano <> wrote:
    > > I disagree that Rick is a troll. Trolling requires that the troll

    >
    > Doesn't matter.  He duck types as one.


    +1

    Intent isn't magic. If Rick intends to contribute, he could actually
    contribute.
     
    alex23, Jan 15, 2013
    #15
  16. On Mon, 14 Jan 2013 22:54:10 -0800, Rick Johnson wrote:

    > 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



    >> 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?


    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.



    --
    Steven
     
    Steven D'Aprano, Jan 15, 2013
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roedy Green
    Replies:
    12
    Views:
    438
    Martin Gregorie
    Aug 2, 2008
  2. rantingrick
    Replies:
    20
    Views:
    489
    Terry Reedy
    Jul 23, 2011
  3. rantingrick
    Replies:
    0
    Views:
    182
    rantingrick
    Jul 22, 2011
  4. rantingrick
    Replies:
    7
    Views:
    354
    Chris Angelico
    Jul 30, 2011
  5. rantingrick
    Replies:
    1
    Views:
    447
    harrismh777
    Jul 29, 2011
Loading...

Share This Page