[Edu-sig] Using IDLE with students

[Richard Guenther]

Well, after some experimenting on my laptop (Running Ubuntu 7.0.4 with Python 2.5.1), I've narrowed it down to this:

1.  If I start IDLE from usr/bin through the terminal , it appears to run in "normal" mode.
2.  If I start with the icon from Gnome menu applications/programming/IDLE, it does NOT start in "normal" mode, but of course you can go into system/main menu/launcher properties (rt. click) and take the "-n" off.  Any reason why that is the default, though?

What I did was declare a variable in the shell mode, then run a simple script that attempted to print that variable without declaring it first.  In "-n" mode it would print "Assigned in shell" or whatever I had assigned to it in the shell.  In "regular" mode, though, it would raise a traceback error ("a" is not defined).

What I find interesting, though, is that in both cases ("-n" and "normal") 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.

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 ... :-(

Ah well, at least my ubuntu menu launches IDLE in "normal" mode now. :-)

Richard

----- 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 environment.

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

-- 
John M. Zelle, Ph.D.             Wartburg College
Professor of Computer Science    Waverly, IA     
john.zelle at wartburg.edu          (319) 352-8360  







       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20070816/66ec8ef9/attachment-0001.htm