On Tue, Jan 20, 2009 at 1:52 AM, David MacQuigg <macqu...@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. It's a change in gestalt, especially if you start with the old one. > If my Animals class hierarchy seems artificial, it may be because I tried to > illustrate everything I considered important, and do it in the smallest > example that would still be clear. The comparison of classes to modules is > not motivated by any affinity to Perl. What little I know of Perl, I don't > like. Rather, it is part of an answer to the question "Why do we need > classes?" Modules are the closest thing to classes as a unit of > encapsulation. With a simple function, you could generate instances of > modules as easily as instantiating objects from classes. You could even > change the language slightly, and allow multiple modules per file. > I'm biased against modules because I start at the shell and don't care about saving any .py files for awhile, have no interest in anything but the current namespace, like a white board. My simplest unit is the primitive object, like 1 or 'a', an integer or string. We do a dir on both of these, show they "have guts" i.e. are endowed with methods. So a number like 2 is a primitive name space, in containing (encapsulating) a lot of behaviors. Next up, data structures or collections, things like iterables, like lists, tuples. Each supports dot notation to methods, has an interior. With functions, you the user start getting more mutable stuff to play with. You can set attributes on function objects (a type of callable). So by the time we get to classes (types), we already have plenty of micro-ecologies as examples, all without every saving a module if we like. The .py format is for persistence, but it's like entering all those lines in the shell really fast, even grabbing your own command line arguments via sys.args. Modules define name spaces, for sure. Use dot notation for access. Also, remember __init__.py is a kind of intercepting at the modular level in that you're customizing the behavior of 'import'. In this sense, there's a class-like aspect to a directory of .py files (to import is to __init__). This is not a direct contradiction of any point you've made, just a hook to the package concept. > As for making OOP a "revelation", I think that is the wrong way to teach it, > especially for non-CS students. I much prefer to treat it as just another > way to encapsulate pieces of a program, a way that is very natural when you > are modeling objects in the real world, and can be beneficial even when there > is no parallel in the real world - the benefit flowing from the extra > flexibility you have in encapsulation. That is something all engineers will > understand. The "revelation" approach completely turned me off when I first > read about OOP in the early 90's. As a skeptical engineer, I was left with > the impression that OOP, polymorphism, etc., was a pile of hype, and there > was nothing there I couldn't do in FORTRAN, BASIC, or C. It wasn't until I > started using Python in 2002, that I saw the benefits. I like that Python > doesn't mystify OOP, or push it the way Java does, but just makes it a > natural thing to do. > Yes, that transition to OOP was upsetting as a paradigm change. I went through it on the xBase path, following dBase II (derived from some JPL language) through its winged migration, fork off to Clipper, FoxPro, buyout by Microsoft and Borland, FoxPro for Windows, Visual FoxPro. The full OO paradigm came across, unlike for the VB crowd, who didn't get that until later. This all happened in my little world *before* I ever wrote a line of Python (plus I got to Java first). APL was the first computer language I ever learned (loved it), then FORTRAN (yawn). However, the real benefit of OO is it hooks to natural language, where students in human languages, like Sumerian, like Greek, already know about nouns, verbs and adjectives as parts of speech. OO is all about noun.verb() and noun.adjective. Then with have these little cartoons about sharing pointers (names) to objects and we're done, they're convinced there's a real grammar here, a logic, and dive in, happy to still be in the humanities, no talk of "computer hardware" need apply (though it's handy to have). This isn't "hyping" so much as "bridging". In industry, it's about town-gown relations, where "town" is an administrative layer atop cube farmers, and "gown" is IT. With ORM, we're finally starting to get admin enrolled in seeing it from IT's point of view, whereas SQL by itself was just not friendly enough. OO makes computing more personable. To have busy administrators see 'self' as like "a little ego with a personal __dict__ clipboard" is not "dumbing it down" is rather taking advantage of well-worn patterns in grammar, leveraging what we've already got. It's efficient. Don't just say "is a", say "I am a". This isn't just cute, it's a conceptually smart way to think about a hospital, school or airport (objects all). But that's me to busy administrators, not you to enrolled electrical engineers. Different audiences = different patter, we both know that. > Again, if anyone wants to modify this document for their own purposes, I'll > be glad to help. > > -- Dave > Thank you for making your work public and open source in this way. You are kind to offer it up for comments and to handle the feedback graciously, especially given my many different biases. Kirby [ Barack Obama about to get sworn in, make his speech -- new president object ] _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig