[Visualpython-devel] Re: [Idle-dev] Py-CVS Release 2.1 Merge

[David Scherer]

> > I also would like to see Windows specific hacks that make 
> it possible 
> > to invoke IDLE as the editor by right-clicking any .py or .pyw file 
> > and selecting "Edit File" from the context menu, even if 
> IDLE already 
> > runs.  This may only work when the win32all extensions are loaded.

As Bruce says, this is only an installer issue: a few Windows registry
entries need to be created.  I routinely do this by hand on machines
that I use heavily for Python coding :)

> > When the goal is learning Python (rather than physics), I find the 
> > shell the best tool there is.
> 
> For the reasons given in my own postings, which have probably crossed 
> yours, I respectfully but forcefully disagree. Both Ruth Chabay and I 
> individually tried hard to learn Python in the shell 
> environment and both 
> of us just got very confused. We didn't want to see what one 
> statement did, we wanted to put several statements together.

Maybe this last sentence is the bottom line.

Here is the first code from Guido's Python tutorial:

>>> 2+2
4
>>> # This is a comment
... 2+2
4
>>> 2+2  # and a comment on the same line as code
4
>>> (50-5*6)/4
5
>>> # Integer division returns the floor:
... 7/3
2
>>> 7/-3
-3

Here is the very first code from an introduction on the VPython website:

from visual import *

redbox=box(pos=vector(4,2,3), size=(8.,4.,6.),color=color.red)
greenball=sphere(pos=vector(4,7,3), radius=2, color=color.green)

The reason that the shell seems great for beginners to Guido and
terrible to Bruce is that Guido thinks of teaching Python by building
upwards from the statement level, so that the first thing needed is lots
of experience with the results of (roughly) individual statements.  The
amount of state is purposely kept minimal at the beginning: in the quote
above, there aren't even any assignments, only expressions.  

In contrast, Bruce and Ruth's course starts with graphics at the very
beginning, and graphics are inherently stateful.  The three-line
fragment above creates quite a bit of state!

Almost immediately, Bruce and Ruth might have the objects moving (I made
this code up, but it's in the right spirit):

from visual import *

redbox=box(pos=vector(4,2,3), size=(8.,4.,6.),color=color.red)
greenball=sphere(pos=vector(4,7,3), radius=2,
                 color=color.green, velocity=vector(0,-1,0))

while 1:
    rate(100)
    greenball.pos += greenball.velocity * 0.1

It's fairly obvious that typing this into the shell is no good.  For
example, going back and changing an initial condition (let's give the
ball velocity (0.1,-1,0) and see what happens) would be a major
operation.

At around the same subjective time, Guido is playing with lists:

>>> a = ['spam', 'eggs', 100, 1234]
>>> a
['spam', 'eggs', 100, 1234]
>>> a[0]
'spam'
>>> a[3]
1234
>>> a[-2]
100
>>> a[1:-1]
['eggs', 100]
>>> a[:2] + ['bacon', 2*2]
['spam', 'eggs', 'bacon', 4]
>>> 3*a[:3] + ['Boe!']
['spam', 'eggs', 100, 'spam', 'eggs', 100, 'spam', 'eggs', 100, 'Boe!']

Later, he introduces classes:

>>> class Complex:
...     def __init__(self, realpart, imagpart):
...         self.r = realpart
...         self.i = imagpart
... 
>>> x = Complex(3.0,-4.5)
>>> x.r, x.i
(3.0, -4.5)

Using the editor for this type of tutorial would be just as awkward.
For example, you would have to write "print" everywhere to get any
output, and the output wouldn't be usefully lined up with the program.

The bottom line (in my mind) is that there is, in fact, a place for both
the editor and the shell - but not necessarily in the same curriculum.
I can imagine an uber-debugger that might be a true superset of both
editor and shell, but I don't have time to write it ;)

Dave