Hi Elaine,
There is a separate mailing list for people who teach Python
as opposed to people learning Python. They might have a
more pertinent view on this. However, for what its worth
here are my views...
> students who already know one programming language.
The language they know might make a big difference.
For example if they know Lisp or Smalltalk then the
aspects of Python that will be familiar are very diffferent
than if they know C++/Java.
> 1) Programming Style
>
> while 1:
> x = next()
> if not x: break
Personally I don;t like this style either, its not intuitive
and harder to read, but it is now the standard Python
idiom in many cases. The reason for this is that you
cannot use assignment in the test in Python, as you
can with C/C++ etc so you would need to repeat the
assignment:
x = func()
while x:
doit()
x = func()
Some folks don't like the double assignment and so prefer
while 1
x = func()
if not x: break
doit()
Personally I prefer the first version...
> 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.
GOTO is no longer consider quite as evil as it used to be... :-)
It just has to be used with discretion.
> complex conditions in a loop use multiple if's with
> break's
I agree, and this can be a significant barrier to the
understanding and use of boolean expressions.
Its quite common to see that on this mailing list,
although I admit we very rarely pick it up and comment.
> 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.
Again I agree.
> I have always thought of break and continue as hacks
> that are not compatible with structured programming
> techniques.
In a pure sense you are right because strictly speaking
structured programming requires a single exit point in
a function or block. But break/continue are not the only
culprits here, multiple return statements have the same
effect. In practice multiple returns and break/continue
can improve the readibility of code significantly as well
as the performance. (And this is also true of GOTO which
is why academics are giving GOTO a cautious rebirth)
> The only exception is using break in a switch in C,
> C++ and Java.
And that's purely because the switch statement, like
so much else, is a badly designed construct in both
languages. The default position should be to exit the
case condition at the end of the block, not fall through
to the next block!.
> However, all Python books seem to contain sample
> programs like this one. Do you think that code like
> this is desirable?
No, but it is standard Python idiom so for the sake of
students underdstanding other people's Python code
you probably need to teach it - although you might
leave it to near the end, after showing the alternatives!
OTOH I don't discuss break/continue in my tutor until
into the advanced topics... And didn't use them at all
in the original vesion (c 1998) or in the book.
> 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?
The functional programming aspects can be left out,
argument matching, if you mean what I think, is quite
important in a dymanically typed language. I'd keep that in.
If you teach list comprehensions you will make the
map/filter/reduce set almost irrelevant anyway.
> 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?
If they already know Java then teach Jython.
Otherwise Teach Tkinter because
1) its the python standard
2) its best documented
3) its pretty easy
4) it has a limited widget set (but explore Tix too) which
is easy to extend
5) its based on Tk which is also the standard GUI for
Tcl and Perl - and there are versions of it for Lisp and C.
HTH,
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
