I'm reading John Zelle's book, a real CS1 text book with exercises, using Python as the language.

This is an exciting book (see my concluding remarks below). I agree with the blurbs on the back. E.g. Russell May of Morehead State University writes "This text does an excellent job of filling a gaping hole in

Python community -- a textbook for an introductory computer science class... It is as good a text as I have read for CS1."

Zelle has a lot of experience teaching CS1, back to Pascal days. I

On Friday 12 December 2003 14:00, Kirby Urner wrote: the trust

his sense of what belongs in a CS1 course in your average community or 4-year college. It's a fairly gentle slope by design, and Python makes it gentler.

What frustrates me somewhat is that CS1 doesn't really show off the full power of Python, and by the time we get to CS2 at Zelle's academy (and I'm suspecting this will be somewhat typical), we're on to Java. The reasoning is solid: real CS majors need exposure to a static-typed language, as well as to more than one language. I have no problem with this reasoning.

We've (Capital University in Columbus, OH) used John's book (prepublication copies) the last two years in CS1 and I agree that it's a great book for beginners. When I taught CS 2 this year, I used a mixture of Python and C++. I started with Python and covered basic data structures (stacks, queues, linked-lists, trees) and operator overloading. I was able to cover this in about 1/2 to 2/3 the time it previously took me to cover this material in C++. I then spent the last part of the course introducing C++ and covering the same topics in C++ (along with the details of dynamic memory management). Overall it worked well (especially considering this was the first time I'd tried it and didn't have a textbook for it), but the students felt they weren't very good at C++ programming. I basically made my own course notes and had the students buy a CS2 C++ book so they had C++ code to look at and mimic. I'm toying with the idea of writing a book that covers CS2 topics with Python and C++ as described above but given my workload, it would be a couple years before it was done and writing prose isn't my favorite thing to do so I'm almost hoping someone will beat me to it. In our advanced data structures I had juniors who had been taught CS1/CS2 with C++ and sophomores who had learned Python and 6 weeks of C++. Many of the juniors had seen some Python from seminar presentations and a software engineering project the year before. I started out with a double-linked lab and paired up the students so I had one "Python student" and one "C++ student". I had one or two groups with "two Python students" but tried to make these some of the better students. I had them writed the lab in Python and then convert it to C++. This worked very well and the "Python students" gained confidence in their C++ skills. Most of the other labs were done with students working by themselves and I let them choose which language they wanted to use. Not surprisingly only a few students chose C++ for the other projects (and I even offered bonus points for labs written in C++ since it would be more work).

The frustrating part is this means cool CS2-level features of Python may not get much if any airplay. Syntax overloading is not taken up, and many OO concepts get only initial treatment (e.g. no discussion of class vs. instance properties/methods, nor of multiple inheritance). No list comprehensions, generators, regular expressions. No passing of functions as parameters to other functions. No numarray, nor much use of the standard library beyond math, random, string and Tkinter (which last is wrapped in a simpler module, graphics.py). No default or optional parameters.

Try-except *is* covered, as is eval() and docstrings.

Again, I'm not questioning Zelle's judgment re what's appropriate to CS1. He has long experience in this domain. He's fully aware of what Python can do, and just had to make these necessary cuts. It's probably somewhat painful to him as well, as when James Cameron (movie director) had to cut out reel three of 'Aliens' in order to have it fit the movie-house time constraints of the day (reel three is restored in the extended play version).

So let's assume a future in which Python is wildly successful as a CS1 language, but with this pattern of moving on for CS2, with the sense

Python has well-prepared students to tackle something thornier. Given

bright future, I still have this lingering concern that Python may eventually be typecast as a "beginner language" in the sense of being not sophisticated enough for higher level development.

As Guido concludes in his short forward: "Reader of this book, congratulations! You will be well rewarded for studying Python. I

Some (but obviously not all) of those topics seem beyond CS2 to me. In my programming languages class I have students work in groups of 3-4 and present a language to the class at the end of the semester. They write a few programs to demonstrate some of the features of the language. In the past, students have chosen Python, Perl, Ruby, Visual Basic, C#, PHP, etc. This January since the students will already know Python I'm considering letting one group do an "advanced Python" where they would cover many of the topics listed in the previous paragraph. that this promise

you'll have fun along the way, and I hope you won't forget your first language once you have become a proficient software developer."

I think it's this hope that I'm echoing as a concern. How will we ensure that Python continues to receive attention even *beyond* its considerable virtues as a beginner's language?

I'm not overly worried about this. As most of us do, the students find writing code in Python more enjoyable. As long as instructors allow the students to use Python in some of the upper-level classes, I think students will learn more about Python and see how powerful a language it is as well as an excellent language for beginners.

When I try to think about how to get deeper into Python within a CS curriculum, I come up with a few ideas:

(a) push more compsci content into the earlier grades so that CS1 might move more quickly from the beginning, and therefore get further. E.g. if a lot of the students coming in already know some Python, this would be ideal.

About the only thing I've pushed into CS1 is GUI code (not the traditional event loop) that John's graphics.py module makes very accessible.

(b) keep the Python thread alive in CS2 even as Java is introduced, with the potential to bridge the two using Jython. This keeps Python around for contrast. This may actually be closer to Zelle's own approach, as he mentions at his website using Python as "pseudo code" for Java-based implementations (but then current Java doesn't do operator overriding, so some cool features of Python would still be missed using this approach).

I agree with this, but think it makes more sense to use C++ so the students get a feel for the lower level issues (memory management) that Java hides and the operator overloading issue you mention. We have a two credit Java course (with a CS 2 prerequisite) that most of our students take since they see it as important for their resume.

(c) think about returning to Python in CS3, if there is such.

(d) return to Python in some of the more specialized classes having to do with graphics, computational geometry, statistics or other specific applications (a recommendation similar to (c) I suppose).

I think a programming languages course is a great place to cover some of the advanced topics (whether the instructor covers it or has the students do a presentation on it). And again, allowing students to use Python for some upper-level courses seems sufficient to keep their interest in learning more about Python.

(e) keep jiggering with the CS1 curriculum to squeeze more in, even if students do not come in more prepared.

When considering option (e), my attention goes to the Point class. If all a Point does is hold x and y coords, then a class implementation seems

I'm not certain how feasible this is. For us, Python allows us to spend more time on problem solving (vs. C++ where we spent time dealing with syntax issues, compiler errors, etc.). I think that (problem solving) is more important in CS1 than advanced Python features. like

overkill in Python. You could get by with built-in tuples. But what if we make a Point slightly more interesting by making it a Vector? Then you can put in __add__ __sub__ __mul__ and __neg__, as well as length(self) and maybe even dot(self,other) and cross(self,other) -- do one in the text, leave the other for an exercise. Then there's conversion to/from polar/spherical coordinates.

Such a Vector might still be used as a parameter to Rectangle and Circle constructors, as in the current version, i.e. it could start out as a simple (x,y) container, and gradually mature as new OO ideas are mentioned.

Another approach would be to add a chapter called something like 'Looking Ahead' or 'Advanced Python', wherein a lot of these cool features were covered rather quickly and briefly, the intent being to give students a foretaste. Those students most enamored of programming and wanting to move more quickly, could be directed to this chapter and a for-further-reading section.

I'd rather see this in a CS2 book.

However, none if this is about detracting from the worth of the text as it stands. I believe Zelle is perfectly positioned to press Python's case, and is doing a very credible and creditable job of it.

He's clear in his intro that his goal is less to teach Python than to give an overview of important computer science concepts that students will re-encounter in just about any language. He's consciously eschewing certain Python idioms (list comprehensions?) in favor of a more generic approach because mastery of Python per se is not the main goal. I understand his reasoning.

Through his efforts, I'm hoping we quickly get to the point where "arguing for Python" as a CS1 language becomes a no-brainer, i.e. it's not even a point of controversy. I think this text moves us a big step in that direction. It's clear, it works, and it should easily go into multiple future editions.

Kirby

I hope so too. Dave

Hello all, I've been reading the thread about my book with great interest. All feedback is helpful, even when I don't necessarily agree. Let me just say that I thought Kirby's initial posting was right on target. My book is intended as a CS1 book, not a book on Python. Because of that, I have been a little fearful about how the book might be received in the Python community. Kirby clearly understands the distinction being drawn, and I appreciate the way his remarks are framed. I am much less concerned than others about how the more advanced and/or indiosyncratic features of Python are/might be taught. The truth is that the tradtional core computer science sequence CS1 (Intro to programming), C2 (Data Structures and Design), CS3 (Advanced Data structures and Algorithms) have not been "about" language for a long time. Even a student that goes through this sequence using a single language, whether that be C++, Java, or Python will not acquire expert knowledge of the language. That's simply not what these courses are about. The point is that once a student has completed CS1/CS2, they can pick up a good technical book and have the foundation to learn the complete feature set of any language. Students continue programming throughout their CS programs and in future careers. They are constantly changing tools. With some serious early exposure to a variety of tools (say dynamic and static languages) they are in a better position to pick tools that are best suited for the job at hand. A move to Java or C++ in CS2 should not be seen as "abandoning" Python. In fact, seeing Python side-by-side with Java ususally leads my students to want to do more Python projects (and hence learn more about Python) in their upper-level classes. Without seeing a statically typed language, it's hard to appreciate the elegance and flexibility of Python. For example, when we talk about polymorphism in CS1, the students say "of course, what's the big deal." Only when they see the complexity of doing similar things in C++ or Java do they really appreciate the concept. Whatever approach one takes to the first classes, it is important to realize that our students do not begin programming with the same background that we have. Most of my students are not particularly mathematically or scientifically oriented (at least at the start). And they are concrete, not abstract thinkers. It's important that we try to meet them where they are so that they can learn and grow with minimal frustration. Packing more into CS1 is probably not the way to do that. Along similar lines, Kirby's comment on abstracting geometric objects from their realizations (see below) are absolutely right on track as a matter of design principle. I do address this sort of decoupling toward the end of the book (model-view architectures). However, the goal of the graphics package is somewhat different. The purpose is to introduce objects in a very concrete way. It is a graphics library, not a geometry library. A Point doesn't really represent an abstract geometric point, but a postion _in_a_window_. Similarly, the Rectangle is not a general mathemetical abstraction, but an actual box on the screen (maybe I should have called it "box"). Now an object on the screen has inherent properties such as color and outline width as instrinsic properties; whereas the mathematical abstraction does not. This is most evident in the Line class. A Line on the screen is not really a line in the mathematical sense---at best it would be a line segment. If you were designing an application around the mathematical concepts you could use the primitives of the graphics library to visually realize some of those (so the graphics package would be analogous to the backend, not the front). Of course, I do use the graphics package to get my students to do things like calculating points of intersection and computing coordinate transformations. The beauty of it is that they think they are just drawing pretty pictures :-). My thanks to all of you who have given me both encouragement and criticism on this project. --John Kirby Urner wrote:

Earlier I wrote:

...

When considering option (e), my attention goes to the Point class. If all a Point does is hold x and y coords, then a class implementation seems like overkill in Python. You could get by with built-in tuples.

Now that I have the student CD, I see that the Point class is not just a holder for (x,y) values. It has some knowledge of Tk, is in fact a subclass of GraphicsObject, which is very Tk aware.

This brings up a design pattern thread for me. My tendency over the years has been to write the geometric objects, such as vectors and polyhedra, in such a way as to deliberately keep them ignorant of any output apparatus.

Then I define a "writer" that's customized to say Tk, or VRML, or POV-Ray, and pass the geometric objects to the writer. The writer squeezes pure geometric information from the things, and translates them into output appropriate to its medium.

You can see evidence of this strategy going all the way back to 1998, when I was still doing this stuff in FoxPro (I hadn't learned of Python yet): http://www.4dsolutions.net/ocn/oop.html

A consequence of this design is I've been putting what philosophers used to call "secondary attributes" (color, texture) in the writer, instead of in the geometric objects. So if I want a red tetrahedron, say, I change to "edge color" and "face color" properties in the writer, before passing a tetrahedron object to it.

E.g.:

...

...

...

povwriter = povray.Povray("outfile.pov") povwriter.cylcolor = 'Red' # secondary attribute obj = rbf.Tetra() # get a tetrahedron obj.draw(povwriter)

But internally to obj.draw(povwriter), I'm invoking povwriter on the various edges, vertices and faces of my obj:

def draw(povwriter):

for e in self.edges(): povwriter.edge(e)

...

and like that.

The upside of this design is if I go obj.draw(vrmlwriter), then the same object gets output in VRML syntax.

In sum, when writing geometric objects to output media, there's a way to go wherein anything specific to the medium is saved to the "writer" object, while anything purely geometric, and common to all media, is saved in the geometric object. The pure geometry is kept separate from the messy details of I/O.

I'm just bringing this up as a by the way. I'm not saying Zelle should have done this in his text book.

It'd be a fruitful discussion for CS2 level course -- when we're talking about design patterns.

Kirby

_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig

-- John M. Zelle, Ph.D. | Wartburg College Associate Prof. of CS | Dept. Math/CS/Physics john.zelle@wartburg.edu | Waverly, Iowa

Kirby Urner wrote:

What frustrates me somewhat is that CS1 doesn't really show off the full power of Python, and by the time we get to CS2 at Zelle's academy (and I'm suspecting this will be somewhat typical), we're on to Java. The reasoning is solid: real CS majors need exposure to a static-typed language, as well as to more than one language. I have no problem with this reasoning.

What I'd like to see in the CS2 w/ Java course in this sequence is some display of how to use Jython To exercise and test your Java code. Often it is a long time before a programmer actually uses more than a single language in a project. By demonstrating this early, you are showing students how to let a pair of languages to "ply to their strengths." I'd also like to see a "learning Java with Jython book, but that's just me. -Scott David Daniels Scott.Daniels@Acm.Org