On Tue, Jan 20, 2009 at 8:45 AM, kirby urner <[email protected]> wrote: > On Tue, Jan 20, 2009 at 1:52 AM, David MacQuigg > <[email protected]> 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. _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
