Elaine wrote:
> I am going to be teaching "Introduction to Python Programming" in the Fall at
> Foothill College in Los Altos Hills, CA.
Great. Welcome to the Python Teachers Association. I'm your "neighbor"
to the north, above Berkeley.
> This is a 5 quarter unit class for students who already know one programming
> language.
>
I presume you mean "at least one".
> I have been teaching programming for 20 years now, including Java and C++ as
> of late.
>
I did it for 10 years. Assembler, APL, BASIC, FORTRAN, PL/I,. Pascal,
REXX, ....
> As I prepare this class, I have some questions that I I am hoping you can
> shed some light on.
>
> 1) Programming Style
>
> while 1:
> x = next()
> if not x: break
>
> I have never allowed students to use break or continue in any programming
> class I have taught. I think of this type of code as belonging with the
> dreaded GOTO.
>
Consider that all "structured" programming statements are some form of
GOTO. The question is not which are and which are not but rather the
effect on readability and maintainability. The alternative to your code
fragment is:
x = True
while x:
x = next()
IMHO the former is easier to read, understand, maintain. It gets even
worse when the terminating condition occurs in the middle of the loop
code. Then we are stuck with:
limit = 45
x = limit
while x >= limit:
x = next()
if x < limit:
do more stuff with x
or
while 1:
x = next()
if x >= 45:
break
do more stuff with x
I'd rather have the 2nd.
> I find that students who are having difficulty writing complex conditions in
> a loop use multiple if's with break's inside the loop instead. Also, it is
> MUCH easier to read a loop if the condition for continuing in the loop is
> right up at the top of the loop where it belongs.
>
In some cases that IS where it belongs. In many others that is
debatable. See my example above. A nice example from
http://en.wikipedia.org/wiki/Control_flow#Early_exit_from_loops:
for n in set_of_numbers:
if isprime(n):
print "Set contains a prime number"
break
else:
print "Set did not contain any prime numbers"
> I have always thought of break and continue as hacks that are not compatible
> with structured programming techniques. The only exception is using break in
> a switch in C, C++ and Java.
>
> However, all Python books seem to contain sample programs like this one. Do
> you think that code like this is desirable?
>
Consider also that a feature of Python is the generator, in which a
function will suspend execution to return (yield) a result, then resume
following the yield statement. Extremely useful, and hard to defend
using a limited view of structured programming.
> 2) Since this is an introductory class, I am tempted to leave out "optional"
> topics like argument matching modes, walk, map, filter, reduce, apply. Do you
> think these are required for any Python programmer?
>
Since many of there will disappear in Python 3 it might be OK to omit
them. OTOH for those of us who come from languages like APL, these
constructs are dear to our hearts.
Also it is worth noting that filter and apply can be rewritten as list
comprehensions, so they can be omitted.
> 3) I need to teach a GUI in this class. I would like something that is easy,
> standard, and multi-platform. I am considering Tkinter and Jython. Any
> opnions on this?
>
Jython is not a GUI.
> Thanks for any answers you might have.
>
Thanks for asking. And good luck with the class. And just for grins see
http://www.fortran.com/come_from.html for FORTRAN's COME FROM statement.
--
Bob Gailer
510-978-4454
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
