> Classes are not a feasible choice to start with because they are a most > complex structure in a programming language that builds on knowledge of > virtually anything else. >
We agree on a lot of points. Because just about any decent Python script makes use of core data structures, such as the list, even if only as a range() return, dot-notation starts to be relevant right from the top. Explaining dot-notation as thing.action(inputs) identifies these "things" as the objects, with dot-notation being a postfix notation for calling, setting and getting. > Indeed, using built-in objects is simpler than defining and using > classes. Still, the concept of objects needs two underlying concepts: > variables and method (function) calls. Object variables are not so > trivial because object assignment is a reference assignment and > therefore creates aliases. Method calls require understanding of > arguments and return values. Thus, it is beneficial to study functions, > variables, and controls structures for a while, before coming to > built-in objects. > Yes, but I still need to explain dot-notation, even in the early days of just doing simple functions. Indeed, I might argue that the simplest intro to conditional flow might be the if clause in list comprehension syntax, i.e. now that we're comfortable with generating in the form [f(x) for x in range(n)], let's now add ... if x%2] or some such. However, the idea of "a list object" should already be in place by this time, i.e. we've looked at [].sort() and so on. Why I'm not so concerned about the fine points of passing by reference, aliases and like that is I'm confidant that class/object thinking is already engrained, simply through exposure to Aristotelian taxonomies. Kids visit the zoo. They understand "cat family" inheriting "mammalian" characteristics, under the kingdom of "animal" (which excludes spinach). So there's your class hierarchy, generic blueprints vs. instances, and individual state variables. Now express that in dot-notation e.g. thetiger.yawns(). In other words, go to the roots of the metaphor and forget about the nitpicky details of computer languages. Come back to that later, but get enough of the concepts to make dot-notation comfortable very early in the game. I'm a philo major, not a CS major, which may account for my willingness to "forget about ... computer languages" from time to time (whenever convenient). > Personally I believe that lists, dictionaries, and strings offer a great > opportunity to introduce objects. There a lot of interesting methods > that can be explored interactively and that can be used to write > interesting programs. Introducing objects with GUIs is OK, but GUI > objects seem to offer fewer opportunities for interactive exploration > than lists, dictionaries, and strings. I'm inclined to agree. On the other hand, I see a need to instill in newcomers that visualization is going to be part of what's coming. They want some assurance up front that graphical content won't be ignored. So sometimes I feel pulled towards GUI-based examples ala John Zelle's graphics.py simply because I know students *want* to go there, and I'm reluctant to resist them. That being said, I don't like doing *only* GUI-based examples. Anyway, IDLE is a GUI, so if you're doing shell in IDLE, you're ipso facto using a GUI (the same could be said of an x-term window). > I cover class definitions as a last theme in my CS1 with Python course. > The continuation is CS2 with Java, an entirely class-oriented course. No > CS2 student has ever complained that classes seem unnatural or difficult > to understand. This is because, I believe, classes come at the right > time - after all underlying concepts have been well understood. > > Atanas Radenski > mailto:[EMAIL PROTECTED] http://www.chapman.edu/~radenski/ > I think this is a viable and likely-to-be-popular approach. Use Python for a first year, then switch gears and get more heavily into OO at the same time, say with Java or C# or... Some will encourage Jython (which I have no problem with -- wish I had more time to play with it). My own framework is based in somewhat different assumptions: pre-college students trying to avoid learning everything twice, once *with* dot-notation and once without. My working hypothesis: the class/object metaphor is useful enough to merit inclusion of dot-notation in mainstream K-12 mathematics. For example, if you want to invert a matrix, write thematrix.invert() -- presuming its invertible. Or you can still write thematrix**(-1) too if you like (operator overloading at your service). So in my course, we're learning about matrices, vectors, polynomials, integers modulo N *as objects*. It's a "programming to learn" course, i.e. the use of Python is a means to an end: a stronger conceptual grasp of various core mathematical ideas, algorithms, ways of approaching a problem. We have yet to clearly differentiate between CS and traditional mathematics at this level (that comes later, when it comes time to specialize). Kirby _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig