Re: [Edu-sig] Using IDLE with students

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@wartburg.edu> To: edu-sig@python.org Cc: Richard Guenther <heistooheavy@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@wartburg.edu (319) 352-8360 ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/

On 8/16/07, Richard Guenther <heistooheavy@yahoo.com> wrote:
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
IDLE is this REPL (read, evaluate, print loop) in the namespace __main__. If you run a program as an argument to python i.e. as top-level, that's __main__ too (but without any REPL -- unless you code that in). So it makes sense that if you're in one of IDLE's text windows, say looking at test.py and go F5 and/or choose Run, that __main__ now gets the benefit of whatever gets executed. That's because you've just elected to run test.py top-level. However, if you just *import* test.py, even though test.py will be evaluated, top-to-bottom, it will *not* populate __main__ because it was not run top level, only imported. Example: test.py has the single line of code: a = 1 If you are in that test.py code window and Run it top level, you will (a) prompt a restart of IDLE (if not using -n) and (b) inherit the contents of __main__ when it's done running:
===== RESTART =====
a 1
On the other hand, if you new restart the shell (purging all but the default namespace), and simply *import*, then the variable 'a' will not be accessible *except* through the namespace of 'test':
===== RESTART ===== import test a
Traceback (most recent call last): File "<pyshell#6>", line 1, in <module> a NameError: name 'a' is not defined
test.a 1 ==========
This behavior holds even if you have no subprocess, but then, instead of IDLE rebooting __main__ from the menu (or automatically when choosing Run), you need to exit IDLE and come back in, in order to clear __main__'s namespace. Kirby

On Thursday 16 August 2007 8:40 pm, Richard Guenther wrote: <<snip>>
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. --John
----- Original Message ---- From: John Zelle <john.zelle@wartburg.edu> To: edu-sig@python.org Cc: Richard Guenther <heistooheavy@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@wartburg.edu (319) 352-8360
participants (3)
-
John Zelle
-
kirby urner
-
Richard Guenther