Re: [Edu-sig] Python First: Free access for educators
Another way people write switch:
def switch(choice): if 0<choice<len(functions): ...
This seems a good thing to do. In terms of complexity, functions come after selection, and that is how they are sequenced in the Python First pack. The material is based on functions all way, from the very beginning, but a systematic coverage of functions is offered *after* control structures. Thus, I would not use functions as parameters or list/tuple members as early as when I cover selection. Fortunately, I can possibly add the implementation of switch (above) as an optional lab in the chapter on functions or in the chapter on lists and dictionaries. [Detailed self-guided labs in Python First are fundamental in 'teaching programming as a habit' - I would love to write on this in a later post.] I know this list is a most sophisticated Python audience. Any feedback is appreciated. I can also explain my chosen pedagogy, should that need arise. Cheers, Atanas Atanas Radenski -- Visit http://studypack.com for new Python and Java resources.
-----Original Message----- From: kirby urner [mailto:kirby.urner@gmail.com] Sent: Wednesday, March 08, 2006 7:51 AM To: Radenski, Atanas Cc: edu-sig@python.org Subject: Re: [Edu-sig] Python First: Free access for educators
Cool, I'm in. Checking out your moodle.
Another way people write switch:
def switch(choice): if 0<choice<len(functions):
I know this list is a most sophisticated Python audience. Any feedback is appreciated. I can also explain my chosen pedagogy, should that need arise.
Cheers,
Atanas
Hi Atanas -- My broad brush stroke philosophy in this context is we're in the early stages of pioneering effective ways of teaching programming, in Python or any other language. How a language gets taught is not an easy business to describe and involves much trial and error. As a consequence, I am not eager to lay down any strict rules about how it should or must be done. Too early to get strident. Like, I'll be trying underunder-style operator overriding (overloading) as early as the 4th week, because I'm just using Python as a means to an end: what this is *really* about is the Vector type in math. Python is just a notation. But that's not necessarily the standard CS approach. The CS idea of heaven (as in "stairway to") seems to be: put Python students on an escalator to the even greater delights of Java (angel music, shaft of light). I mutter something about Bruce Eckel liking Python better, but usually under my breath, as I sense a fanatical gleam in their CS faculty eyes.[1] Anyway, my bottom line is: teach Python in any way you feel you're effective at. Teachers *cannot* simply pick up other teachers' skills and techniques at the drop of a hat. We're reprogrammable, but not *that* reprogrammable. I can't be you and you can't be me. So we shouldn't worry if our own style and effectiveness is not a carbon copy of someone else's. My Python moodles are very much geared to Algebra students. I'm looking at Polynomials, Polyhedra, Vectors and Rationals as "types in an extensible type system" with Python's OO illustrating what I mean by that (but it even kinda meant that pre-Python and pre formalized OO). So is this what I think everyone should be doing in their own respective moodles? Absolutely not. Then I'd feel a lot more redundant, and maybe have to find a new gig. But for now, my gig is pretty unique, and that suits me just fine (which doesn't mean I don't welcome competitors). Kirby [1] http://pythonjournal.cognizor.com/pyj2/Eckel.html
participants (2)
-
kirby urner -
Radenski, Atanas