[Edu-sig] Topics for CS2

kirby urner kirby.urner at gmail.com
Tue Jan 20 19:44:45 CET 2009

On Tue, Jan 20, 2009 at 8:45 AM, kirby urner <kirby.urner at gmail.com> wrote:
> On Tue, Jan 20, 2009 at 1:52 AM, David MacQuigg
> <macquigg at ece.arizona.edu> wrote:
> <<>>
> [ watching Obama motorcade on CRT to my left, typing to LCD on my laptop ]
>> There may be some misunderstanding as to my purpose in writing this chapter.  It is not a CS1 introduction to OOP.  I would recommend Zelle or Goldwasser for that.  It was written before those texts, and specifically for engineers who already know some programming, understand very well the need for modular design (no need for motivation of OOP), and who have learned Python up through chapter 18 of Lutz and Ascher (no need to explain __notation__).  It could be an alternative, or a supplement, to the OOP chapters in L&A.  It could also be part of the CS2 class I am now proposing, for students who already know Java or C.
> Probably I was confusing your "module" and "modular" (cite Perl below)
> in that you relate Objects to both, which of course makes sense, in
> terms of encapsulated name spaces.  Classes, unlike mere modules, have
> progeny, ancestors, spawn multiple instances of themselves without
> duplicated more bits than necessary.  You're clear about this
> distinction, which I liked.
> Your role as the teacher most specializing (customizing) to these
> students is a good example of how curriculum writing itself has a
> modular aspect, and a subclassing (tiering) from more to less
> generalized.  You've got a very specific mix in mind, a certain type
> of sophistication.  I likewise have my different biases.
> On a scale of 1-10, overriding __del__ in the process of doing
> subclass instance counting in a parent class, is like 8 or 9,
> especially where you bring __mro__ into it.  So yes, I see your desire
> to include arcana.  You're being respectful of your students' already
> high level of initiation.
>> Some of my choices on what topics to emphasize may be different.  These choices were based on my own experience, which may be different than others, and is certainly different from those who have a less pragmatic approach to languages.  Thus, I have relegated operator over-riding to "advanced topics" because of my perception that it will be used less often than say, static methods, which I have included in my first large example.  I use static methods frequently.  They are now (as of version 2.4) more "pythonic" than when this chapter was written, so I feel I made the right choice.
> I'm inclined to see + and * in a continuum with [] and (), in that the
> former trigger __add__ and __mul__ whereas the latter trigger
> __getitem__ and __call__ (or __init__).
> In other words "operator over-riding" tends to blend in with all
> manner of syntax-invoked method triggering.  The fact that * + and
> such used to be segregated as "immutable operators" gets forgotten in
> the rough and tumble.
> We don't keep quite the same unary / binary fixation either, in that
> a.__add__(b) is an act of consumption (a eats b, maybe returns c of
> some type), just as is f(1) an act of consumption (swallowing a name).
>  a * b is a "munch" operation, in that __mul__ (or __rmul__) is
> getting invoked.
> In the old days, I tell my students, numbers were stupid, they
> couldn't do anything, didn't know anything.  Operators descended from
> heaven, like space ships, and caused numbers to be added and
> multiplied.
> But in Python, everything is a snake, a live object, including numbers
> like 1 and 2, and they have knowledge of addition and multiplication
> "in their bones" (__ribs__).  When you go 1 * 2, that's not a space
> ship, bristling with static methods from on high, from the alien
> "knows operations" land, that's invoking an innate ability of the
> integer type.

I made a fun cartoon out of the above:


My more technical argument, about how OO changes our view of
operators, in this older paper, where my nouns are quaternions:



> It's a change in gestalt, especially if you start with the old one.

More information about the Edu-sig mailing list