[Edu-sig] Using IDLE with students
john.zelle at wartburg.edu
Fri Aug 17 05:25:12 CEST 2007
On Thursday 16 August 2007 8:40 pm, Richard Guenther wrote:
> you are still able to access variables that have just run in a program
> after the program is done running. For instance, if I run a program that
> declares a="assigned in program", I can later print out that variable in
> shell mode.
Yes, this is true if your script manipulates global variables. It is
equivalent to running the python interpreter on the script using the -i flag,
which leaves you in interactive mode after executing the script. Again, you
can get a "clean" slate by simply going to the shell menu and selecting
restart. This happens automatically if you run another script, each time you
hit <F5> you get a clean run, and then you can play around with the results
afterwords. The important thing is that the next run is not "tainted" it
happens in a clean namespace.
As I mentioned before, you can also "protect" against this by simply writing
your programs in functions to avoid global variables.
I personally put my scripts in a function called main, and I execute that. If
I want some data to hang around so that I can play with it, then I poke it
into a global variable or two.
> So I've worked several Python books and tutorials, written both functional
> programs and some OOP, and yet I find myself not real clear on what exactly
> IDLE is ... :-(
It's not really too mysterious if you're used to read-eval-print loops. The
main thing is you need a good understanding of things that produce
side-effects. Globals variables are always tricky in that way. The fact that
built-in functions are not reserved in Python is just a little extra twist
(e.g. you can redefine things like raw_input).
> Ah well, at least my ubuntu menu launches IDLE in "normal" mode now. :-)
Yeah, now you run into the problem that you can only have 1 IDLE process
running at a time. I don't understand why IDLE uses a fixed port.
> ----- Original Message ----
> From: John Zelle <john.zelle at wartburg.edu>
> To: edu-sig at python.org
> Cc: Richard Guenther <heistooheavy at yahoo.com>
> Sent: Wednesday, August 15, 2007 9:13:32 AM
> Subject: Re: [Edu-sig] Using IDLE with students
> On Wednesday 15 August 2007 9:04 am, Richard Guenther wrote:
> > Sorry if this is a bit simplistic:
> > When teaching Python to beginners and using IDLE, it seems that one of
> > the dangers would be to have them assigning variables in the interactive
> > mode and then maybe using them in a script they're writing. Then, when
> > they run the script, the variable is still in memory so the program
> > works--for now.
> > Or, as happened recently "raw_input" gets accidentally assigned to a
> > string. Then, any programs that end with "raw_input("Press Enter to exit
> > this program")" will cause an error, even though the program script
> > itself is fine.
> > Obviously quiting and reloading IDLE will take care of this, but I was
> > wondering what else may trip up students using IDLE. Maybe it would be
> > nice if IDLE had an option called "Run fresh" that would clear any
> > variables first....just musing here.
> Provided you start IDLE in the "normal" mode, running scripts should
> execute in a separate subprocess, so the kinds of interactions you describe
> here are not really a problem. When running in this mode, you can also do a
> "restart" under the shell menu, and this will get you a fresh interactive
> The problem is that the default IDLE setup in some environments starts up
> IDLE with the -n switch that causes it to run without separate subprocesses
> for scripts. For example, under Windows, if you right-click on a Python
> program and then select "edit with IDLE" it will open in the no-subprocess
> mode. I always have my students create a shortcut to IDLE in their working
> directories and make sure it starts IDLE without the -n switch, and I
> emphasize starting IDLE and then loading programs.
> By the way, another thing that will really help is getting students in the
> habit of writing scripts as functions and then just calling the function.
> That way variables are local to the function/script regardless of how IDLE
> is running (still doesn't solve problems like reassigning built-in
> functions though).
John M. Zelle, Ph.D. Wartburg College
Professor of Computer Science Waverly, IA
john.zelle at wartburg.edu (319) 352-8360
More information about the Edu-sig