On Tue, Jan 20, 2009 at 8:45 AM, kirby urner <kirby.urner@gmail.com> wrote:
On Tue, Jan 20, 2009 at 1:52 AM, David MacQuigg <macquigg@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: http://mybizmo.blogspot.com/2009/01/transitions-of-power.html My more technical argument, about how OO changes our view of operators, in this older paper, where my nouns are quaternions: http://www.4dsolutions.net/ocn/oopalgebra.html Kirby
It's a change in gestalt, especially if you start with the old one.