From kirby.urner at gmail.com  Fri Aug  3 17:47:04 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 3 Aug 2007 08:47:04 -0700
Subject: [Edu-sig] Interesting thread...
Message-ID: <f604188c0708030847s5ddfa655hf474e4f4a136c390@mail.gmail.com>

For CS teachers interested in matters Pythonic:

http://lambda-the-ultimate.org/node/1840

Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20070803/e1636cf2/attachment.htm 

From kirby.urner at gmail.com  Fri Aug  3 18:20:31 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 3 Aug 2007 09:20:31 -0700
Subject: [Edu-sig] Interesting thread...
In-Reply-To: <f604188c0708030847s5ddfa655hf474e4f4a136c390@mail.gmail.com>
References: <f604188c0708030847s5ddfa655hf474e4f4a136c390@mail.gmail.com>
Message-ID: <f604188c0708030920s9cc89c8j815f14edbde99fb2@mail.gmail.com>

On 8/3/07, kirby urner <kirby.urner at gmail.com> wrote:
>
>
> For CS teachers interested in matters Pythonic:
>
> http://lambda-the-ultimate.org/node/1840
>
> Kirby
>
>
Providing some of my own feedback:

There's this "MIT mystique" where part of the fascination is
all the Hogwartsian bureaucracy (the attribute "Kafkaesque"
comes to mind):  Course VI, with such as 6.001 and 6.099,
unchanged in 20 years.

That these courses are "barely doable" just adds to their
flamboyance.    Tinkering with the core language mix, therefore,
is *significant* (if you're buying into the MIT mystique, which
most of us do (e.g. see my "Mayan thread" @ Math Forum)).

I like the idea of controlling a robot, but question whether
turtle "move" commands will be needed.  The tux droid has
wings that flap, eyes the open and close... but it just spins
on its butt, doesn't walk (apropos penguins, who maybe do
it a lot, but not very well).

Easier for computer lab use, a stationary bot.

import tux
tux.cmd.lefteye_open()
tux.rotate_on_butt(3)  # quarter turns

stuff like that.

Beyond that, I think MIT is banking on its students being
highly competitive and questioning this Pythonic approach.
They'll learn other languages, as an expression of their
academic freedom to do so.

What are we losing by moving to Python?  Lambda calculus
rears from the ocean, a Legendary Beast.

What if we forget about lambda?  Alonso Church et al?

"Guido is a lamba hater" someone warns.

Reminds me of pleasant chats in greener pastures with
Tim Peters, about "little lambda" (Kirby:  "we like our
lambdas little, make do sans the big woolly Scheme
sheep").

Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20070803/5a66b12f/attachment.htm 

From kirby.urner at gmail.com  Fri Aug  3 19:24:34 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 3 Aug 2007 10:24:34 -0700
Subject: [Edu-sig] Interesting thread...
In-Reply-To: <f604188c0708030920s9cc89c8j815f14edbde99fb2@mail.gmail.com>
References: <f604188c0708030847s5ddfa655hf474e4f4a136c390@mail.gmail.com>
	<f604188c0708030920s9cc89c8j815f14edbde99fb2@mail.gmail.com>
Message-ID: <f604188c0708031024r23638be1t1052bbe82ecfc150@mail.gmail.com>

> Easier for computer lab use, a stationary bot.
>
> import tux
> tux.cmd.lefteye_open()
> tux.rotate_on_butt(3)  # quarter turns
>
> stuff like that.


Adding some crunchy realism, since I have said droid connected to this
Ubuntu Dell:

Python 2.5.1 (r251:54863, May  2 2007, 16:56:35)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path.append('/home/kirby/tuxsetup-1.0-final/tuxdroid/doc/examples')
>>> sys.path.append('/home/kirby/tuxsetup-1.0-final/tuxdroid/api/python')
>>> import tux
CONNECTED to tuxd
CONNECTED to tuxttsd
>>> tux.cmd.eyes_close()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'cmd'
>>> from tux import *
>>> tux.cmd.eyes_close()
>>> tux.cmd.eyes_open()
>>> tux.cmd.soundtest()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'TUXcmd' object has no attribute 'soundtest'
>>> tux.cmd.sound_test()
>>> tux.tts.speak("Hello World!")
True
>>>


Alonso Church et al?
>
> "Guido is a lamba hater" someone warns.


Not so fast ... <http://lambda-the-ultimate.org/node/1840#comment-22427>

Chris, You had better nix the 'lambda's -- Guido is a lambda
hater<http://www.artima.com/weblogs/viewpost.jsp?thread=98196>.
;-)
By Rick Hanson <http://lambda-the-ultimate.org/user/3538> at Mon, 2006-11-20
00:06 | login <http://lambda-the-ultimate.org/user/login> or
register<http://lambda-the-ultimate.org/user/register>to post comments



Reminds me of pleasant chats in greener pastures with
> Tim Peters, about "little lambda" (Kirby:  "we like our
> lambdas little, make do sans the big woolly Scheme
> sheep").
>
> Kirby
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20070803/439b6061/attachment.html 

From mtobis at gmail.com  Fri Aug  3 20:17:03 2007
From: mtobis at gmail.com (Michael Tobis)
Date: Fri, 3 Aug 2007 13:17:03 -0500
Subject: [Edu-sig] interactive vs compiled from file
Message-ID: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>

One problem I have consistently had with beginners is in explaining
the difference between how the interpreter produces output without an
explicit 'print' statement (producing the str() of the last evaluated
expression) and how python run from a file does not.

This is perfectly natural and useful for an experienced user, but it
is awkward and confusing for the beginner, who has enough of a
cognitive load just trying to track all the pieces.

This leads to two (well, four) questions:

1) How have you folks addressed this problem in your beginning
classes? Do you find it causes difficulties?

2) Would it be difficult to provide an alternative interpreter that
produced nothing unless you asked it to print? Would this be a good
idea?

thanks
mt

From andre.roberge at gmail.com  Fri Aug  3 21:29:19 2007
From: andre.roberge at gmail.com (Andre Roberge)
Date: Fri, 3 Aug 2007 16:29:19 -0300
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
References: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
Message-ID: <7528bcdd0708031229t485b7eees8d3bddb9614a49f3@mail.gmail.com>

On 8/3/07, Michael Tobis <mtobis at gmail.com> wrote:
>
> One problem I have consistently had with beginners is in explaining
> the difference between how the interpreter produces output without an
> explicit 'print' statement (producing the str() of the last evaluated
> expression) and how python run from a file does not.
>
> This is perfectly natural and useful for an experienced user, but it
> is awkward and confusing for the beginner, who has enough of a
> cognitive load just trying to track all the pieces.
>
> This leads to two (well, four) questions:
>
> 1) How have you folks addressed this problem in your beginning
> classes? Do you find it causes difficulties?
>
> 2) Would it be difficult to provide an alternative interpreter that
> produced nothing unless you asked it to print? Would this be a good
> idea?



I'll reserve judgement as to whether or not this is a good idea, but it's
possible to do - at least, according to a quick implementation I tried with
Crunchy.

*If* this is a desirable feature, and assuming my quick test is correct, I
could include it as yet another type of interpreter available within
Crunchy.  :-)

Andr?

P.S. it would need a name to distinguish it from the normal interpreter.
(un-parrot?)


thanks
> mt
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20070803/db8095e3/attachment.html 

From kirby.urner at gmail.com  Fri Aug  3 21:34:29 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 3 Aug 2007 12:34:29 -0700
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
References: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
Message-ID: <f604188c0708031234w35ba5193r77caff572200ea7f@mail.gmail.com>

On 8/3/07, Michael Tobis <mtobis at gmail.com> wrote:
> One problem I have consistently had with beginners is in explaining
> the difference between how the interpreter produces output without an
> explicit 'print' statement (producing the str() of the last evaluated
> expression) and how python run from a file does not.
>
> This is perfectly natural and useful for an experienced user, but it
> is awkward and confusing for the beginner, who has enough of a
> cognitive load just trying to track all the pieces.
>
> This leads to two (well, four) questions:
>
> 1) How have you folks addressed this problem in your beginning
> classes? Do you find it causes difficulties?
>
> 2) Would it be difficult to provide an alternative interpreter that
> produced nothing unless you asked it to print? Would this be a good
> idea?
>
> thanks
> mt

How about explain that Python in "shell mode" is actually like
running a script such as this one:

=========== Repl.py ==============

# baby shell (cave painting)

def repl():
    while True:
        mycommand = raw_input(">>> ")

        # assignment or function def ?
        if "=" in mycommand or "def " in mycommand: # easily broken
            exec mycommand in locals(), globals()

        # quitting?
        elif mycommand == "exit()":
            break

        # treat as an expression
        else:
            # don't do anything stupid
            print eval(mycommand)

repl()
print "Thank you for using Python"

In use:

kirby at dell:~$ python ./repl.py
>>> def f(x): return x * x
>>> f(10)
100
>>> a = f(90)
>>> a
8100
>>> 1 + 2
3
>>> exit()
Thank you for using Python

Even if they don't get all the code, the point is that "shell mode" is an
active evaluation loop with a raw_input like prompt and persistence
in memory (scope).

Simply feeding a mou.. er module to our snake makes it crunch
through the code without invoking this "live action debugger" (this
"shell").

Memory is still populated of course, but expressions evaluated without
any namespace bindings may just vanish into thin air -- unless they
have other side-effects -- because there's no 'print eval(myexpression)'
loop in effect.

Kirby

From andre.roberge at gmail.com  Fri Aug  3 23:02:13 2007
From: andre.roberge at gmail.com (Andre Roberge)
Date: Fri, 3 Aug 2007 18:02:13 -0300
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <7528bcdd0708031229t485b7eees8d3bddb9614a49f3@mail.gmail.com>
References: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
	<7528bcdd0708031229t485b7eees8d3bddb9614a49f3@mail.gmail.com>
Message-ID: <7528bcdd0708031402g5b802ac7kc3e6787c9af766cf@mail.gmail.com>

On 8/3/07, Andre Roberge <andre.roberge at gmail.com> wrote:
>
>
>
> On 8/3/07, Michael Tobis <mtobis at gmail.com> wrote:
> >
> > One problem I have consistently had with beginners is in explaining
> > the difference between how the interpreter produces output without an
> > explicit 'print' statement (producing the str() of the last evaluated
> > expression) and how python run from a file does not.
> >
> > This is perfectly natural and useful for an experienced user, but it
> > is awkward and confusing for the beginner, who has enough of a
> > cognitive load just trying to track all the pieces.
> >
> > This leads to two (well, four) questions:
> >
> > 1) How have you folks addressed this problem in your beginning
> > classes? Do you find it causes difficulties?
> >
> > 2) Would it be difficult to provide an alternative interpreter that
> > produced nothing unless you asked it to print?
>
>
If you want to give it a try, here's what you need to do.

Find the code.py module in the standard library.  Replace 'single' by 'exec'
in runsource() i.e.

    def runsource(self, source, filename="<input>", symbol="single"):
by
    def runsource(self, source, filename="<input>", symbol="exec"):

To run it:
import code
code.interact()

Unless I am missing something, this should do the trick.

Ideally, one would change the prompt too so as to distinguish it from the
regular interpreter.

Andr?

Would this be a good
> > idea?
>
>
>
> I'll reserve judgement as to whether or not this is a good idea, but it's
> possible to do - at least, according to a quick implementation I tried with
> Crunchy.
>
> *If* this is a desirable feature, and assuming my quick test is correct, I
> could include it as yet another type of interpreter available within
> Crunchy.  :-)
>
> Andr?
>
> P.S. it would need a name to distinguish it from the normal interpreter.
> (un-parrot?)
>
> thanks
> > mt
> > _______________________________________________
> > Edu-sig mailing list
> > Edu-sig at python.org
> > http://mail.python.org/mailman/listinfo/edu-sig
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20070803/5bee4999/attachment.htm 

From delza at livingcode.org  Fri Aug  3 23:17:50 2007
From: delza at livingcode.org (Dethe Elza)
Date: Fri, 3 Aug 2007 14:17:50 -0700
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
References: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
Message-ID: <94D49592-6BCD-44B3-9338-EB89BDA9ECA6@livingcode.org>

On 3-Aug-07, at 11:17 AM, Michael Tobis wrote:

> 2) Would it be difficult to provide an alternative interpreter that
> produced nothing unless you asked it to print? Would this be a good
> idea?

 >>> 'abc'
'abc'
 >>> import sys
 >>> def f(value): pass
...
 >>> sys.displayhook = f
 >>> 'abc'
 >>>

So if you add a do-nothing displayhook in your site.py, or as part of  
a standard local import, you won't have the echo behaviour.

HTH

--Dethe

"It goes against the grain of modern education to teach children to  
program. What fun is there in making plans, acquiring discipline in  
organizing thoughts, devoting attention to detail and learning to be  
self-critical?" --Alan Perlis



From mtobis at gmail.com  Fri Aug  3 23:41:40 2007
From: mtobis at gmail.com (Michael Tobis)
Date: Fri, 3 Aug 2007 16:41:40 -0500
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <94D49592-6BCD-44B3-9338-EB89BDA9ECA6@livingcode.org>
References: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
	<94D49592-6BCD-44B3-9338-EB89BDA9ECA6@livingcode.org>
Message-ID: <c3aa55550708031441y101328eao6795136f9908478@mail.gmail.com>

Thanks, Dethe, that's very nice, and also thanks for your signature,
which is thought provoking indeed.

Does anyone agree with me about the didactic value of this change?

mt

On 8/3/07, Dethe Elza <delza at livingcode.org> wrote:
> On 3-Aug-07, at 11:17 AM, Michael Tobis wrote:
>
> > 2) Would it be difficult to provide an alternative interpreter that
> > produced nothing unless you asked it to print? Would this be a good
> > idea?
>
>  >>> 'abc'
> 'abc'
>  >>> import sys
>  >>> def f(value): pass
> ...
>  >>> sys.displayhook = f
>  >>> 'abc'
>  >>>
>
> So if you add a do-nothing displayhook in your site.py, or as part of
> a standard local import, you won't have the echo behaviour.
>
> HTH
>
> --Dethe
>
> "It goes against the grain of modern education to teach children to
> program. What fun is there in making plans, acquiring discipline in
> organizing thoughts, devoting attention to detail and learning to be
> self-critical?" --Alan Perlis
>
>
>

From kirby.urner at gmail.com  Sat Aug  4 00:10:02 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 3 Aug 2007 15:10:02 -0700
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <c3aa55550708031441y101328eao6795136f9908478@mail.gmail.com>
References: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
	<94D49592-6BCD-44B3-9338-EB89BDA9ECA6@livingcode.org>
	<c3aa55550708031441y101328eao6795136f9908478@mail.gmail.com>
Message-ID: <f604188c0708031510n4ceb9097j946dfad37729941d@mail.gmail.com>

On 8/3/07, Michael Tobis <mtobis at gmail.com> wrote:
> Thanks, Dethe, that's very nice, and also thanks for your signature,
> which is thought provoking indeed.
>
> Does anyone agree with me about the didactic value of this change?
>
> mt

If you put duct tape over the snake's mouth in shell mode,
students might discover they miss the REPL, which helps
motivate a sense of why so many successful languages
(LISP, Scheme, APL, J... xBase) have such a mode.

http://en.wikipedia.org/wiki/REPL

(note:  this article suggests not confusing REPL with "an
interpreter" citing Python in particular).

Asked what about Python most drew them in, many newbies
cite shell mode (e.g. iPython, IDLE, PyCrust, DrPython or whatever).

-- Kirby

Another project in the Crunchy genre?
http://projects.amor.org/misc/wiki/HTTPREPL

From andre.roberge at gmail.com  Sat Aug  4 00:30:59 2007
From: andre.roberge at gmail.com (Andre Roberge)
Date: Fri, 3 Aug 2007 19:30:59 -0300
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <f604188c0708031510n4ceb9097j946dfad37729941d@mail.gmail.com>
References: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
	<94D49592-6BCD-44B3-9338-EB89BDA9ECA6@livingcode.org>
	<c3aa55550708031441y101328eao6795136f9908478@mail.gmail.com>
	<f604188c0708031510n4ceb9097j946dfad37729941d@mail.gmail.com>
Message-ID: <7528bcdd0708031530j3b47999ct55813bd5ffa3f1b6@mail.gmail.com>

On 8/3/07, kirby urner <kirby.urner at gmail.com> wrote:
>
> On 8/3/07, Michael Tobis <mtobis at gmail.com> wrote:
> > Thanks, Dethe, that's very nice, and also thanks for your signature,
> > which is thought provoking indeed.
> >


Yes, thanks Dethe.  And your pointer about sys.displayhook may be just what
was needed so that I could embed IPython as an alternative shell within
Crunchy - without interfering with the other shells!   I just need to
experiment a bit more...


> Does anyone agree with me about the didactic value of this change?
> >
> > mt


Well, I do - I had to explain this very difference between the behaviour of
the interpreter and that of an editor [inside Crunchy :-)] to my son last
week; I managed to get him started on "How to think like a computer
scientist".  :-) :-)

 How would you call that mode to distinguish it from the standard
interpreter, and warning your students that this is a non-standard
implementation?

If you put duct tape over the snake's mouth in shell mode,
> students might discover they miss the REPL, which helps
> motivate a sense of why so many successful languages
> (LISP, Scheme, APL, J... xBase) have such a mode.
>
> http://en.wikipedia.org/wiki/REPL
>
> (note:  this article suggests not confusing REPL with "an
> interpreter" citing Python in particular).
>
> Asked what about Python most drew them in, many newbies
> cite shell mode (e.g. iPython, IDLE, PyCrust, DrPython or whatever).


Kirby got a good point - however, I think that you'd still get the "hook"
with newbies without the automatic echoing that Michael describes.


-- Kirby
>
> Another project in the Crunchy genre?
> http://projects.amor.org/misc/wiki/HTTPREPL


Crunchy 0.1 was very much inspired by this same project from Robert Brewer -
the original code built on that example.  It wasn't until version 0.3, I
believe, that Johannes Woolard removed the CherryPy dependency (
http://pytute.blogspot.com/2006/05/progress-so-far.html) allowing Crunchy to
evolve significantly since.

 Andr?

_______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20070803/dc65ca12/attachment.html 

From delza at livingcode.org  Sat Aug  4 01:02:05 2007
From: delza at livingcode.org (Dethe Elza)
Date: Fri, 3 Aug 2007 16:02:05 -0700
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <7528bcdd0708031530j3b47999ct55813bd5ffa3f1b6@mail.gmail.com>
References: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
	<94D49592-6BCD-44B3-9338-EB89BDA9ECA6@livingcode.org>
	<c3aa55550708031441y101328eao6795136f9908478@mail.gmail.com>
	<f604188c0708031510n4ceb9097j946dfad37729941d@mail.gmail.com>
	<7528bcdd0708031530j3b47999ct55813bd5ffa3f1b6@mail.gmail.com>
Message-ID: <E18ACA5D-FF43-40F9-AE65-80BC8B238128@livingcode.org>

> > Thanks, Dethe, that's very nice, and also thanks for your signature,
> > which is thought provoking indeed.

I'm glad you found the snippet helpful (and also the sig).

> Yes, thanks Dethe.  And your pointer about sys.displayhook may be  
> just what was needed so that I could embed IPython as an  
> alternative shell within Crunchy - without interfering with the  
> other shells!   I just need to experiment a bit more...

That's cool, glad to play a part in the evolution of Crunchy.

> > Does anyone agree with me about the didactic value of this change?

Apart from the challenge of being able to turn off echoing, I'm not  
convinced it's a good idea.  It seems to me that it should be  
relatively easy to explain.  Also, with the naive replacement of the  
displayhook I demonstrated, you lose the underscore value (normally  
in the interpreter the _ variable holds the last result that was  
echoed).  This is useful when exploring, because sometimes you will  
test several things, and then when it works, you have it saved in _  
without having to retrace your steps.  I'm more inclined to go  
further and use IPython (which has vastly *more* changes from the non- 
interactive Python runtime) for all the nice tools it gives explorers.

On the other hand, my kids are just now starting to explore Python,  
so I don't have much practical experience to share.  Yet.

Unrelated digression:

My six-year-old is trying to program Python in Scratch, which is  
interesting, because he doesn't really know anything about Python  
beyond "you type in words and it does stuff." So he's essentially  
inventing parsing on his own, in a language that makes text parsing  
amazingly difficult.  Scratch makes getting the basics very easy, but  
I think by the time I get my PyGame-based scratch-like environment  
ready for my kids, they will find Python's relative lack of arbitrary  
limits to be very refreshing.

--Dethe

Every day computers are making people easier to use. --David Tompkin



From kirby.urner at gmail.com  Sat Aug  4 01:38:37 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 3 Aug 2007 16:38:37 -0700
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <7528bcdd0708031530j3b47999ct55813bd5ffa3f1b6@mail.gmail.com>
References: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
	<94D49592-6BCD-44B3-9338-EB89BDA9ECA6@livingcode.org>
	<c3aa55550708031441y101328eao6795136f9908478@mail.gmail.com>
	<f604188c0708031510n4ceb9097j946dfad37729941d@mail.gmail.com>
	<7528bcdd0708031530j3b47999ct55813bd5ffa3f1b6@mail.gmail.com>
Message-ID: <f604188c0708031638o723f79kab18fef2944b0cb0@mail.gmail.com>

On 8/3/07, Andre Roberge <andre.roberge at gmail.com> wrote:

> Kirby got a good point - however, I think that you'd still get the "hook"
> with newbies without the automatic echoing that Michael describes.
>

Not sure we should call this "echoing" as what's happening
is an expression is being evaluated.

It just so happens that the eval of a quoted string returns
itself  whereas "some expression with %s" % "substitution"
would actually evaluate to non-echo.

kirby at dell:~$ python ./repl.py
>>> 'THIS IS A STRING'
THIS IS A STRING
>>> [x*x for x in range(10)]
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
>>> "1-2-3 %s" % "testing"
1-2-3 testing

Would one turn off all of the above, or just the first eval-print?

What would be the point of a broken shell, vs explaining that
Python, like many languages, features a REPL (read-eval-print loop)?

Kirby

From andre.roberge at gmail.com  Sat Aug  4 01:59:00 2007
From: andre.roberge at gmail.com (Andre Roberge)
Date: Fri, 3 Aug 2007 20:59:00 -0300
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <f604188c0708031638o723f79kab18fef2944b0cb0@mail.gmail.com>
References: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
	<94D49592-6BCD-44B3-9338-EB89BDA9ECA6@livingcode.org>
	<c3aa55550708031441y101328eao6795136f9908478@mail.gmail.com>
	<f604188c0708031510n4ceb9097j946dfad37729941d@mail.gmail.com>
	<7528bcdd0708031530j3b47999ct55813bd5ffa3f1b6@mail.gmail.com>
	<f604188c0708031638o723f79kab18fef2944b0cb0@mail.gmail.com>
Message-ID: <7528bcdd0708031659r6f42a3f5v10576e5573ae821a@mail.gmail.com>

On 8/3/07, kirby urner <kirby.urner at gmail.com> wrote:
>
> On 8/3/07, Andre Roberge <andre.roberge at gmail.com> wrote:
>
> > Kirby got a good point - however, I think that you'd still get the
> "hook"
> > with newbies without the automatic echoing that Michael describes.
> >
>
> Not sure we should call this "echoing" as what's happening
> is an expression is being evaluated.
>
> It just so happens that the eval of a quoted string returns
> itself  whereas "some expression with %s" % "substitution"
> would actually evaluate to non-echo.
>
> kirby at dell:~$ python ./repl.py
> >>> 'THIS IS A STRING'
> THIS IS A STRING
> >>> [x*x for x in range(10)]
> [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
> >>> "1-2-3 %s" % "testing"
> 1-2-3 testing
>
> Would one turn off all of the above, or just the first eval-print?
>
> What would be the point of a broken shell, vs explaining that
> Python, like many languages, features a REPL (read-eval-print loop)?
>
> Kirby
>
I don't see it as "either or", but as "why not allow both?".    I agree
entirely with the strength of the REPL.  However, when going from that to
having code saved in a file and executed, a huge step occurs (which is what
Michael was referring to I believe) in that to see something output, the
user *must* put in an explicit print statement.

What I envisage right now is to continue to have the default shell using in
Crunchy (prompt = ">>>") and give the possibility to have a "parrot" shell
(obligatory Monty Python reference; he's not dead.  He may not be replying
... but he's just sleeping).   Perhaps the prompt could be

u_)       (parrot lying on its side, two feet up, beak pointing up; sorry
Kirby, the parrot's ribs are too small to see).

I could see a teacher giving a few interactive examples with this shell,
have the students play with it for a short while, and then move on to saving
files and running them.     ... Just something to ease the transition from
the friendly REPL to writing standalone scripts.

@Michael: is this what you had in mind?

Andr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20070803/8326d5ab/attachment-0001.htm 

From delza at livingcode.org  Sat Aug  4 02:24:00 2007
From: delza at livingcode.org (Dethe Elza)
Date: Fri, 3 Aug 2007 17:24:00 -0700
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <f604188c0708031638o723f79kab18fef2944b0cb0@mail.gmail.com>
References: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
	<94D49592-6BCD-44B3-9338-EB89BDA9ECA6@livingcode.org>
	<c3aa55550708031441y101328eao6795136f9908478@mail.gmail.com>
	<f604188c0708031510n4ceb9097j946dfad37729941d@mail.gmail.com>
	<7528bcdd0708031530j3b47999ct55813bd5ffa3f1b6@mail.gmail.com>
	<f604188c0708031638o723f79kab18fef2944b0cb0@mail.gmail.com>
Message-ID: <C10FA0F5-EAF5-4EBA-91E9-423DF875C47C@livingcode.org>

On 3-Aug-07, at 4:38 PM, kirby urner wrote:

> Not sure we should call this "echoing" as what's happening
> is an expression is being evaluated.

No, the expression is being evaluated either way, all we are doing is  
turning off the default echoing of the expression result (and the  
side-effect of assigning the expression result to the underscore  
variable).

> It just so happens that the eval of a quoted string returns
> itself  whereas "some expression with %s" % "substitution"
> would actually evaluate to non-echo.

What the normal displayhook does is echo the result of non-None  
expressions, and assign those to _.  What the little hack I showed  
did is replace that default behaviour with a no-op, a do-nothing.   
Whether this is a good idea or not is a different matter, but let's  
be clear about what's happening.

> kirby at dell:~$ python ./repl.py
>>>> 'THIS IS A STRING'
> THIS IS A STRING
>>>> [x*x for x in range(10)]
> [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
>>>> "1-2-3 %s" % "testing"
> 1-2-3 testing
>
> Would one turn off all of the above, or just the first eval-print?

Not sure what you're asking.  None of the evals are being changed,  
just the default echoing.  If you then want to print you could either  
assign it to a variable and print that, or pass the whole expression  
through print.  Again, I'm not saying this is a good thing, but it is  
more consistent with how the non-interactive runtime works.

> What would be the point of a broken shell, vs explaining that
> Python, like many languages, features a REPL (read-eval-print loop)?

Well, it might be useful to show learners that a) this is different  
from what you should expect when you run your program, and b) it is  
not magic.  For instance:

 >>> ''
''
 >>> 'abc'
'abc'
 >>> 'my name is %s' % 'Dethe'
'my name is Dethe'
 >>> import sys
 >>> def noecho(value): pass
...
 >>> def echo(value):
...     print value
...
 >>> def echo_and_assign(value):
...     print value
...     global _
...     _ = value
...
 >>> sys.displayhook = noecho
 >>> 'abc'
 >>> sys.displayhook = echo
 >>> 'abc'
abc
 >>> _
<built-in function displayhook>
 >>> sys.displayhook = echo_and_assign
 >>>

Now we've re-implemented the default behaviour (modulo any edge cases  
it handles that I've missed).  And if we want to completely get back  
to the default, after playing around with the displayhook, that's  
easy too:

 >>> sys.displayhook = sys.__displayhook__ # always returns  
displayhook back to system default

Or if we want something to happen every time we eval a line in the  
interpreter:

 >>> def enhanced_display(value):
...     sys.__displayhook__(value)
...     do_my_stuff()
...
 >>> sys.displayhook = enhanced_display

It's all fun and games, until someone loses their ribs.  ;-)

--Dethe

Language is what something becomes when you think in it -- Robert  
Bringhurst



From kirby.urner at gmail.com  Sat Aug  4 02:25:32 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 3 Aug 2007 17:25:32 -0700
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <7528bcdd0708031659r6f42a3f5v10576e5573ae821a@mail.gmail.com>
References: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
	<94D49592-6BCD-44B3-9338-EB89BDA9ECA6@livingcode.org>
	<c3aa55550708031441y101328eao6795136f9908478@mail.gmail.com>
	<f604188c0708031510n4ceb9097j946dfad37729941d@mail.gmail.com>
	<7528bcdd0708031530j3b47999ct55813bd5ffa3f1b6@mail.gmail.com>
	<f604188c0708031638o723f79kab18fef2944b0cb0@mail.gmail.com>
	<7528bcdd0708031659r6f42a3f5v10576e5573ae821a@mail.gmail.com>
Message-ID: <f604188c0708031725g35b2051dma11540443c4fd9aa@mail.gmail.com>

> I don't see it as "either or", but as "why not allow both?".    I agree
> entirely with the strength of the REPL.  However, when going from that to
> having code saved in a file and executed, a huge step occurs (which is what
> Michael was referring to I believe) in that to see something output, the
> user *must* put in an explicit print statement.

OK, but there's a middle ground between REPL and running a .py file,
which is importing library and 3rd party modules *in shell mode*.

My preferred pedagogy (others prefer others) is to

(a) start with REPL (e.g. "using Python as a calculator")

then

(b) move on to such as 'import math' but treating the
module as a 'grab bag of tools' that we use *interactively*
e.g. math.cos(someangle).  At this point, we're ready
for graphical forms of output (e.g. VPython cylinders
and balls), possible robot control ala Logo.

then finally:

(c) standalone .py programs, perhaps taking command line
inputs ala sys.args, perhaps prompting the user with an
old fashioned menu.

(d) if we get to it:  (c) with the added benefit of a GUI.

The transition from (a) to (b) is where we handle the steps
of changing code in the module, doing a reload.

Plus we have the fun of talking about sys.path, dir() and
help(), talking about namespaces more generally,
'import foo' versus 'from foo import x as y'.

The transition to (c) involves looking at python the command
line executable, going python --h for the first time (looking
a switches).

The transition to (d) is where many a Visual Basic programmer
thinks we should *start* e.g. with some simple standalone GUI
program.

Kirby

From kirby.urner at gmail.com  Sat Aug  4 02:35:45 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 3 Aug 2007 17:35:45 -0700
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <C10FA0F5-EAF5-4EBA-91E9-423DF875C47C@livingcode.org>
References: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
	<94D49592-6BCD-44B3-9338-EB89BDA9ECA6@livingcode.org>
	<c3aa55550708031441y101328eao6795136f9908478@mail.gmail.com>
	<f604188c0708031510n4ceb9097j946dfad37729941d@mail.gmail.com>
	<7528bcdd0708031530j3b47999ct55813bd5ffa3f1b6@mail.gmail.com>
	<f604188c0708031638o723f79kab18fef2944b0cb0@mail.gmail.com>
	<C10FA0F5-EAF5-4EBA-91E9-423DF875C47C@livingcode.org>
Message-ID: <f604188c0708031735x6bc77160l1590164d3092f499@mail.gmail.com>

> > kirby at dell:~$ python ./repl.py
> >>>> 'THIS IS A STRING'
> > THIS IS A STRING
> >>>> [x*x for x in range(10)]
> > [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
> >>>> "1-2-3 %s" % "testing"
> > 1-2-3 testing
> >
> > Would one turn off all of the above, or just the first eval-print?
>
> Not sure what you're asking.  None of the evals are being changed,
> just the default echoing.  If you then want to print you could either

I guess it boils down to a quibble over the verb "echoing" -- a source
of confusion for me.

In the first eval above, the output of the eval looks a lot like the input
(hence "echo").

But most expressions evaluate to a result that's different, so what
you call "default echoing" I call "default printing of the results of
evaluation".

We're agreeing that what's happening is always an eval, and we're
agreeing that the print part of REPL could be suppressed, leading
to REL instead.

> > What would be the point of a broken shell, vs explaining that
> > Python, like many languages, features a REPL (read-eval-print loop)?
>
> Well, it might be useful to show learners that a) this is different
> from what you should expect when you run your program, and b) it is
> not magic.  For instance:
>
>  >>> ''
> ''
>  >>> 'abc'
> 'abc'
>  >>> 'my name is %s' % 'Dethe'
> 'my name is Dethe'
>  >>> import sys
>  >>> def noecho(value): pass
> ...
>  >>> def echo(value):
> ...     print value
> ...
>  >>> def echo_and_assign(value):
> ...     print value
> ...     global _
> ...     _ = value
> ...
>  >>> sys.displayhook = noecho
>  >>> 'abc'
>  >>> sys.displayhook = echo
>  >>> 'abc'
> abc
>  >>> _
> <built-in function displayhook>
>  >>> sys.displayhook = echo_and_assign
>  >>>

This doesn't very newbie-accessible to me.

> Now we've re-implemented the default behaviour (modulo any edge cases
> it handles that I've missed).  And if we want to completely get back
> to the default, after playing around with the displayhook, that's
> easy too:
>
>  >>> sys.displayhook = sys.__displayhook__ # always returns
> displayhook back to system default
>
> Or if we want something to happen every time we eval a line in the
> interpreter:
>
>  >>> def enhanced_display(value):
> ...     sys.__displayhook__(value)
> ...     do_my_stuff()
> ...
>  >>> sys.displayhook = enhanced_display
>
> It's all fun and games, until someone loses their ribs.  ;-)
>
> --Dethe

However I think these are *advanced* games.

The original confusion, as I understood it, was "Python in shell mode"
versus "Python running a .py file".  I think we might explain that "shell
mode" is a special script that implements an interactive evaluation loop,
a feature we much appreciate about Python.

Anyway, I'm not here to say "my way or the highway".  If you or Andre
want a "dead parrot mode", why not?  Maybe for some students, the light
will go on and all confusions will dissipate -- which I think is our shared
goal.

Kirby

From delza at livingcode.org  Sat Aug  4 05:13:05 2007
From: delza at livingcode.org (Dethe Elza)
Date: Fri, 3 Aug 2007 20:13:05 -0700
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <f604188c0708031735x6bc77160l1590164d3092f499@mail.gmail.com>
References: <c3aa55550708031117k61002c48w8ae9684a3495b327@mail.gmail.com>
	<94D49592-6BCD-44B3-9338-EB89BDA9ECA6@livingcode.org>
	<c3aa55550708031441y101328eao6795136f9908478@mail.gmail.com>
	<f604188c0708031510n4ceb9097j946dfad37729941d@mail.gmail.com>
	<7528bcdd0708031530j3b47999ct55813bd5ffa3f1b6@mail.gmail.com>
	<f604188c0708031638o723f79kab18fef2944b0cb0@mail.gmail.com>
	<C10FA0F5-EAF5-4EBA-91E9-423DF875C47C@livingcode.org>
	<f604188c0708031735x6bc77160l1590164d3092f499@mail.gmail.com>
Message-ID: <0FE261D0-0293-4465-9320-3F667675EF9F@livingcode.org>

On 3-Aug-07, at 5:35 PM, kirby urner wrote:

> I guess it boils down to a quibble over the verb "echoing" -- a source
> of confusion for me.

I'm not attached to "echoing," that's just what it is called in the  
shell (and the shell is not always right).  I just wanted to clarify  
that we the eval is still happening.

> In the first eval above, the output of the eval looks a lot like  
> the input
> (hence "echo").
>
> But most expressions evaluate to a result that's different, so what
> you call "default echoing" I call "default printing of the results of
> evaluation".

Sure, that's fine.

> We're agreeing that what's happening is always an eval, and we're
> agreeing that the print part of REPL could be suppressed, leading
> to REL instead.

;-)

>>>>> sys.displayhook = noecho
>>>>> 'abc'
>>>>> sys.displayhook = echo
>>>>> 'abc'
>> abc
>>>>> _
>> <built-in function displayhook>
>>>>> sys.displayhook = echo_and_assign
>>>>>
>
> This doesn't very newbie-accessible to me.

No.  That wouldn't be a first lesson.  But maybe for a more  
precocious student, to keep them busy while you get the others in the  
class get caught up...

>> It's all fun and games, until someone loses their ribs.  ;-)
>
> However I think these are *advanced* games.

Agreed.  I got carried away playing with it.  The point is that  
Python has these hooks all over the place, and sometimes when we  
think we need to create a new version of the interpreter, all that is  
needed is to play with the hooks a bit.

> The original confusion, as I understood it, was "Python in shell mode"
> versus "Python running a .py file".  I think we might explain that  
> "shell
> mode" is a special script that implements an interactive evaluation  
> loop,
> a feature we much appreciate about Python.
>
> Anyway, I'm not here to say "my way or the highway".  If you or Andre
> want a "dead parrot mode", why not?  Maybe for some students, the  
> light
> will go on and all confusions will dissipate -- which I think is  
> our shared
> goal.

Absolutely.  I think we can agree to agree.

--Dethe

"Any idea that couldn't stand a few decades of neglect is not worth  
anything." --Gabriel Garcia Marquez



From kirby.urner at gmail.com  Sat Aug  4 17:55:48 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Sat, 4 Aug 2007 08:55:48 -0700
Subject: [Edu-sig] Free Wingware version for students
Message-ID: <f604188c0708040855m149af0e8h1c69f20daa875916@mail.gmail.com>

Probably a lot of you got this annoucement already:

http://wingware.com/wingide-101

Free, not open source, still in beta.  Good Python editor with
integrated shell mode.
I'm planning to play with it -- haven't yet.  Might use it in my next
Saturday Academy
class.

Kirby

From jjposner at snet.net  Sun Aug  5 17:59:54 2007
From: jjposner at snet.net (John Posner)
Date: Sun, 5 Aug 2007 11:59:54 -0400
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <mailman.7.1186221602.25014.edu-sig@python.org>
References: <mailman.7.1186221602.25014.edu-sig@python.org>
Message-ID: <003f01c7d779$aa3f0560$e759a8c0@jposner>

Nice discussion! Here's my suggestion: if the user types an expression that
returns a value, 
have IDLE echo the return value annotated with its type, and with "<<<" as a
prefix. Reversing the direction of the angle brackets is a neat (IMHO) way
to remind the user of the concept of "return value".

Examples:

############################################# set it up

>>> import sys
>>> sys.displayhook = show_expression_value

############################################# show how it works

>>> 23 + 45 - 31
<<< 37              (INTEGER expression value)

>>> 2/3.0
<<< 0.67            (FLOAT expression value)

>>> 'hi' + 'there'
<<< 'hithere'       (STRING expression value)

>>> def f(inp):
        return inp

>>> f('func arg')
<<< 'func arg'      (STRING expression value)

>>> f(2 + 3 + 4)
<<< 9               (INTEGER expression value)

############################################# quiet if return value is None

>>> a = 2 + 3 + 4
>>> a = f(4.56789)


Here's my implementation:

def show_expression_value(val):
    """
    Show expression value or function return value in IDLE.
    Deploy this function with: sys.displayhook = show_expression_value
    """
    if type(val) is type("hello"):
        displayme = "'%s'"  % val
        print "<<< %-15s (STRING expression value)" % displayme
    elif type(val) is type(1):
        displayme = "%d" % val
        print "<<< %-15s (INTEGER expression value)" % displayme
    elif type(val) is type(1.0):
        displayme = "%.2f" % val
        print "<<< %-15s (FLOAT expression value)" % displayme

    # TO DO: more "elif"s for other value types



From andre.roberge at gmail.com  Sun Aug  5 18:27:05 2007
From: andre.roberge at gmail.com (Andre Roberge)
Date: Sun, 5 Aug 2007 13:27:05 -0300
Subject: [Edu-sig] interactive vs compiled from file
In-Reply-To: <003f01c7d779$aa3f0560$e759a8c0@jposner>
References: <mailman.7.1186221602.25014.edu-sig@python.org>
	<003f01c7d779$aa3f0560$e759a8c0@jposner>
Message-ID: <7528bcdd0708050927u5230df29qcb163273147b02a0@mail.gmail.com>

On 8/5/07, John Posner <jjposner at snet.net> wrote:
>
> Nice discussion! Here's my suggestion: if the user types an expression
> that
> returns a value,



This is a fantastic idea to introduce the various types.   I prefer this
over trying to do
type('hello') explicitly at the prompt.

Your implementation works very well too - and not only in IDLE.

Andr?


have IDLE echo the return value annotated with its type, and with "<<<" as a
> prefix. Reversing the direction of the angle brackets is a neat (IMHO) way
> to remind the user of the concept of "return value".
>
> Examples:
>
> ############################################# set it up
>
> >>> import sys
> >>> sys.displayhook = show_expression_value
>
> ############################################# show how it works
>
> >>> 23 + 45 - 31
> <<< 37              (INTEGER expression value)
>
> >>> 2/3.0
> <<< 0.67            (FLOAT expression value)
>
> >>> 'hi' + 'there'
> <<< 'hithere'       (STRING expression value)
>
> >>> def f(inp):
>         return inp
>
> >>> f('func arg')
> <<< 'func arg'      (STRING expression value)
>
> >>> f(2 + 3 + 4)
> <<< 9               (INTEGER expression value)
>
> ############################################# quiet if return value is
> None
>
> >>> a = 2 + 3 + 4
> >>> a = f(4.56789)
>
>
> Here's my implementation:
>
> def show_expression_value(val):
>     """
>     Show expression value or function return value in IDLE.
>     Deploy this function with: sys.displayhook = show_expression_value
>     """
>     if type(val) is type("hello"):
>         displayme = "'%s'"  % val
>         print "<<< %-15s (STRING expression value)" % displayme
>     elif type(val) is type(1):
>         displayme = "%d" % val
>         print "<<< %-15s (INTEGER expression value)" % displayme
>     elif type(val) is type(1.0):
>         displayme = "%.2f" % val
>         print "<<< %-15s (FLOAT expression value)" % displayme
>
>     # TO DO: more "elif"s for other value types
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20070805/d8ca63f9/attachment.htm 

From kirby.urner at gmail.com  Sun Aug  5 19:29:29 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Sun, 5 Aug 2007 10:29:29 -0700
Subject: [Edu-sig] Python types, iterators in particular
Message-ID: <f604188c0708051029r29e33a9emf04ce89786fdb095@mail.gmail.com>

Speaking of types, I'm not seeing a generic 'iterator type' in the types module.
Then we have all these special types for iterable objects:

>>> type(xrange(10))
<type 'xrange'>
>>> type((i for i in range(10)))
<type 'generator'>
>>> type(enumerate((1,2,3,4)))
<type 'enumerate'>
>>> type(iter([1,2,3,4,5]))
<type 'listiterator'>
>>> type(iter((1,2,3)))
<type 'tupleiterator'>

Noting:
"""
(In retrospect, it might have been better to go for __next__()
and have a new built-in, next(it), which calls it.__next__().
But alas, it's too late; this has been deployed in Python 2.2
since December 2001.)
"""
[ http://www.python.org/dev/peps/pep-0234/ ]

Is this part of what's fixed in Python 3.0 then?  Plus there'll be some
type integration under the concept if 'iterator type'?  I've heard Guido's
latest 3.0 talk twice now, and that's the impression I'm left with.

Background to this question (writing about Python 3.0 on another list):

"""
The details are interesting too. What's been emerging in computer
science is this notion of "lazy evaluation" akin to "just in time"
in many dimensions (another important meme). In Python, this was
foretold by xrange, a prophetic __builtin__ in retrospect. xrange
will be simply range in Python 3.x.

What did xrange foretell? Lazy evaluation. Instead of pre-allocating
gobs of memory, just save the algorithm for getting the *next* in
the sequence, only deliver when specifically asked.

Constructs such as 'for p in primes:' don't seem so strange any
more, because 'primes' isn't an infinite chunk of memory, so much
as a factory for a sequence of values, to be delivered conveyor
belt style, but only when a .next() button is pressed.

All that __next__ button pushing takes time, and in the mean time,
Python is off doing other things.

However, this notion of an "iterable" (source of next values) wasn't
so clear in the early days of Python. xrange foretold it, but now
we have explicit generators and generator expressions.

We've since elevated 'iterable' to a known type (a 'duck type' as
we say) and return it more consistently as such, and not just by
xrange (soon to be just range, taking the place of the old memory
pre-allocating version).

These innovations were just not conceived of in the earliest Pythons.
So rather than focusing on Guido's "mistakes" (aka "regrets"), we
have the option to just talk about advances, and Python's amazing
ability to adopt them, cleanly and intelligently (a tribute to its
namesake).
"""

Kirby

From kirby.urner at gmail.com  Wed Aug  8 23:43:17 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Wed, 8 Aug 2007 14:43:17 -0700
Subject: [Edu-sig] When am I the same age as my dog?
Message-ID: <f604188c0708081443n78968764k5e5f189493b28a65@mail.gmail.com>

I may have posted about this awhile back, but it
came up as a real question for a man wanting to
party the day his dog caught up and passed him
in age, assuming one human year = seven dog
years.

It makes a fun Python program as it involves dates,
which are notoriously problematic.  Hint:  Julian dates
might come in handy, plus don't forget leap years.

Another posing of the problem:

Every day I live counts as 1 day, every day a dog lives
counts as 7.  Given a dog born later than myself (date),
and my birthday (date), on which day will my dog and
I have the same number of days to our credit (date)?

I.e.

date  samecount (
date dog_bday, date my_bday
)

Note:  my newest gig involves teaching SQL using Python
in shell mode to start (import MySQLdb **), per my standard
pedagogy:

http://worldgame.blogspot.com/2007/08/sa-pedagogy.html

This courseware is proprietary by mutual consent, so I
won't be saying much more about it here (or anywhere).

Just more of the usual day job.

Kirby

** typical student/teacher interface:

"""
kirby at dell:~$ ssh [xxx]
[xxx] password:
Last login: Wed Aug  8 11:33:46 2007 from [yyy]
[prompt ~]$ python2.5
Python 2.5.1 (r251:54863, Jul 17 2007, 14:30:01)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import MySQLdb
>>> dir(MySQLdb)
['BINARY', 'Binary', 'Connect', 'Connection', 'DATE', 'DATETIME',
'DBAPISet', 'DataError', 'DatabaseError', 'Date', 'DateFromTicks',
'Error', 'FIELD_TYPE', 'ImmutableSet', 'IntegrityError',
'InterfaceError', 'InternalError', 'MySQLError', 'NULL', 'NUMBER',
'NotSupportedError', 'OperationalError', 'ProgrammingError', 'ROWID',
'STRING', 'TIME', 'TIMESTAMP', 'Time', 'TimeFromTicks', 'Timestamp',
'TimestampFromTicks', 'Warning', '__all__', '__author__',
'__builtins__', '__doc__', '__file__', '__loader__', '__name__',
'__path__', '__revision__', '__version__', '_mysql', 'apilevel',
'connect', 'connection', 'constants', 'debug', 'escape',
'escape_dict', 'escape_sequence', 'escape_string', 'get_client_info',
'paramstyle', 'release', 'result', 'server_end', 'server_init',
'string_literal', 'thread_safe', 'threadsafety', 'times',
'version_info']
"""

From goodmansond at yahoo.com  Thu Aug  9 08:04:27 2007
From: goodmansond at yahoo.com (Dean Goodmanson)
Date: Wed, 8 Aug 2007 23:04:27 -0700 (PDT)
Subject: [Edu-sig] snakes ad infinitum
Message-ID: <421910.77988.qm@web51904.mail.re2.yahoo.com>

Greetings Pythoneers,

I pondered far and wide which Python SIG might find
this shirt most captivating and have drawn to a near
conclusion that the EDU-SIG'ers could stomach it. 
Even if this device resembles a spiced ham product.

http://shirt.woot.com/Friends.aspx?k=3656

Be well and never tire the CP4E quest.  Looking
forward to seeing you in Chicago for PyCon `08 next
March.
Anyone need a talk topic?
http://www.google.com/search?q=CP4E+prosumer

-Dean


       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  

From kirby.urner at gmail.com  Thu Aug  9 18:52:35 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 9 Aug 2007 09:52:35 -0700
Subject: [Edu-sig] snakes ad infinitum
In-Reply-To: <421910.77988.qm@web51904.mail.re2.yahoo.com>
References: <421910.77988.qm@web51904.mail.re2.yahoo.com>
Message-ID: <f604188c0708090952m24c44134k2cfc3b12970966f5@mail.gmail.com>

> Anyone need a talk topic?
> http://www.google.com/search?q=CP4E+prosumer
>
> -Dean

<free_commercial>

I followed this link and ended up at
http://www.webfaction.com/
which coincidentally is my new ISP
for 4dsolutions.net.

Digitalspace.net was taken over by
Jumpline.com during OSCON which
(a) screwed up my /presentations
directory just when I wanted to
share contents (b) stopped popping
source code when browsers clicked
on .py files at Oregon Curriculum
Network (c) broke the source code
colorizor (py2html + PyFontify)
(d) broke my cgi scripts around
the MySQL geoquiz demo and
(e) broke an old Python blog I
keep around for historical purposes
(Pybloxsom).

Engineers were making very very
slow progress on my trouble tickets,
telling me to "just be patient"  whereas
at webfaction the on-line documentation
showed me how to restore the .py file
functionality I wanted, gave me easy
access to all the Pythons (2.2, 2.3,
2.5...), whereas jumpline was saying
Python 2.5 would be impossible to
come by.

Yes, it costs a little more, but it's well
worth the extra.  For the same price
I could be using Django or Zope.  But
for my purposes, static HTML with a
little cgi is all I need for now, at least
for this particular domain (not my one
and only).

</free_commercial>

Kirby

From kirby.urner at gmail.com  Mon Aug 13 22:43:20 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 13 Aug 2007 13:43:20 -0700
Subject: [Edu-sig] spinning 'self'
Message-ID: <f604188c0708131343x295fc047md1125f2cab373143@mail.gmail.com>

Python is remarkably liberal in its design, in that 'self' is not a
keyword.  You're free to use other names for this important
place in memory.

Yet there's still self-imposed discipline (another way of saying
'self discipline'), such that we tend to all use 'self' anyway, by
convention (but Python-the-interpreter doesn't complain if we
don't -- not likely to change).

However, as Python teachers have widely remarked, this concept
of 'self' is not easily communicated at first, given the OO paradigm
is itself still coming into focus for some students.

In the class definition, the 'self' is really a 'place holder' (akin to zero)
i.e. it doesn't do any work, but keeps a place open, like a driver's
seat waiting for a driver.

When an *object* of said class is created, the self becomes
specified, as a kind of *anchor*.  And plumbing the depths of
'self' is easy:  all you need is __dict__ (i.e. a self is basically
another namespace, a concept already familiar from earlier
discussions).

Python-by-comic-book (including on the net) is an emerging
genre, influenced by Head First, Dive Into, and For Dummies
series.

I'm storyboarding for comics (could be TV shows) in which
' this ', ' me ' and ' ghost ' each get a crack at occupying
the ' self ' position.  Each of these English options has its
own logic and connotations.

I especially like ' ghost ' because of its ' ghost in the shell '
connotations (a link to manga, the genre we're in).[1]

As Python goes towards Unicode, other "non-Romanji"
substitutes for ' self ' may suggest themselves.

However (back to self-discipline) I think it's wise to stick
to the guidelines and go with non-idiosyncratic forms.

David Goodger was good on this in his 'Idiomatic Python'
at OSCON 2007 [2]:

If your object is an iterable (i.e. has a "duck face" (which is
like being a "duck type" but sounds more like "interface"))
then address as such, as in in 'for myvar in self.__dict__',
and not using has_key() or some such more specialcase
form.

In this same spirit (aha! another one), we just go with 'self'
at the end of the day.

Kirby

[1]
http://www.imdb.com/title/tt0113568/
http://www.imdb.com/title/tt0347246/
(theme song choral sequences some of my all time favorites)

[2] http://oscon07.icalico.org/talk/view/271
Also mentioned in my blogs:
http://controlroom.blogspot.com/2007/07/idiomatic-python.html

From john.zelle at wartburg.edu  Tue Aug 14 02:33:15 2007
From: john.zelle at wartburg.edu (John Zelle)
Date: Mon, 13 Aug 2007 19:33:15 -0500
Subject: [Edu-sig] spinning 'self'
In-Reply-To: <f604188c0708131343x295fc047md1125f2cab373143@mail.gmail.com>
References: <f604188c0708131343x295fc047md1125f2cab373143@mail.gmail.com>
Message-ID: <200708131933.15807.john.zelle@wartburg.edu>

On Monday 13 August 2007 3:43 pm, kirby urner wrote:
> Python is remarkably liberal in its design, in that 'self' is not a
> keyword.  You're free to use other names for this important
> place in memory.
>
> Yet there's still self-imposed discipline (another way of saying
> 'self discipline'), such that we tend to all use 'self' anyway, by
> convention (but Python-the-interpreter doesn't complain if we
> don't -- not likely to change).
>
> However, as Python teachers have widely remarked, this concept
> of 'self' is not easily communicated at first, given the OO paradigm
> is itself still coming into focus for some students.

The nice thing about explicit 'self' from a teaching perspective is that it 
really is not different from other parameters. Once students understand 
parameters (not necesarily an easy thing for them), self does not really 
involve any OO mystery at all. It's just a matter of showing how the 
parameters match up in a method call:

obj.someMethod(actual1, actual2)            someMethod(self, formal1, formal2)

(you'll have to draw the arrows yourself, my font is proportional -- rats!, 
there should be a nice arrow from obj to self, actual1 to formal1 and actual2 
to formal2)

Then of course you explain the reason for the special syntax is that obj is 
what determines where we go looking for the definition of someMethod. The 
actual result is still just a plain old function call.

> In the class definition, the 'self' is really a 'place holder' (akin to
> zero) i.e. it doesn't do any work, but keeps a place open, like a driver's
> seat waiting for a driver.
>
> When an *object* of said class is created, the self becomes
> specified, as a kind of *anchor*.  And plumbing the depths of
> 'self' is easy:  all you need is __dict__ (i.e. a self is basically
> another namespace, a concept already familiar from earlier
> discussions).

I would quibble about self not doing any work (you need it to access its 
attributes), but I understand the point you are making. Again, though this 
makes things seem a bit more mysterious than they really are. The self 
parameter is a placeholder in the exact same sense that all formal parameters 
are place holders for objects that are provided at call time. The self 
parameter has no 'specialness' in this regard.

> Python-by-comic-book (including on the net) is an emerging
> genre, influenced by Head First, Dive Into, and For Dummies
> series.
>
> I'm storyboarding for comics (could be TV shows) in which
> ' this ', ' me ' and ' ghost ' each get a crack at occupying
> the ' self ' position.  Each of these English options has its
> own logic and connotations.
>
> I especially like ' ghost ' because of its ' ghost in the shell '
> connotations (a link to manga, the genre we're in).[1]
>
> As Python goes towards Unicode, other "non-Romanji"
> substitutes for ' self ' may suggest themselves.
>
> However (back to self-discipline) I think it's wise to stick
> to the guidelines and go with non-idiosyncratic forms.

Yes, otherwise you incur the wrath of the Python Gods. Deviation from self 
appears to be  the one form of heresy that is never tolerated under any 
circumstance. "To thine self be true!"

> David Goodger was good on this in his 'Idiomatic Python'
> at OSCON 2007 [2]:
>
> If your object is an iterable (i.e. has a "duck face" (which is
> like being a "duck type" but sounds more like "interface"))
> then address as such, as in in 'for myvar in self.__dict__',
> and not using has_key() or some such more specialcase
> form.

Huh? I'm affraid I don't follow this. If my object (meaning self?) is 
iterable, I doubt that I intend to iterate through its namespace.  If the 
point is simply not to use keys() as the iterable sequence for a dictionary, 
whether it's self.__dict__ or any other dictionary,  that I get.

> In this same spirit (aha! another one), we just go with 'self'
> at the end of the day.
>

And all is right with the world.

--John

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

From kirby.urner at gmail.com  Tue Aug 14 06:30:16 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 13 Aug 2007 21:30:16 -0700
Subject: [Edu-sig] spinning 'self'
In-Reply-To: <200708131933.15807.john.zelle@wartburg.edu>
References: <f604188c0708131343x295fc047md1125f2cab373143@mail.gmail.com>
	<200708131933.15807.john.zelle@wartburg.edu>
Message-ID: <f604188c0708132130j2c5e5c72y2b4deb1f6ce5e553@mail.gmail.com>

On 8/13/07, John Zelle <john.zelle at wartburg.edu> wrote:

> I would quibble about self not doing any work (you need it to access its
> attributes), but I understand the point you are making. Again, though this
> makes things seem a bit more mysterious than they really are. The self
> parameter is a placeholder in the exact same sense that all formal parameters
> are place holders for objects that are provided at call time. The self
> parameter has no 'specialness' in this regard.

Yes, I agree.  What's special about 'self' is simply what you mentioned
above:  it gets passed "silently" and you need take special care to have
a variable (usually 'self') ready for it as the first parameter of your method
definition -- but then don't mention it when you call in (' self ' is "implied"
-- what makes it special).

But the purpose of 'self' comes into its own when you have a million
'selves' (or just ten) all instantiated from the very same class definition.

Then we start to appreciate how each of those million has its own
state, its own anchor in memory, thanks to 'self' (or whatever) and in
turn self.__dict__.

There's nothing much else to distinguish two objects of the same type.
' self ' objectifies objects, and as such isn't really called upon to play
its role until an object is instantiated (i.e. gains a self).

I forgot to suggest 'I' (capital 'eye') as an interim possibility (in addition
to candidates ' this ', ' ghost ', ' me ') though of course that's hard to
decipher in ASCII (looks just like Number One).

> Yes, otherwise you incur the wrath of the Python Gods. Deviation from self
> appears to be  the one form of heresy that is never tolerated under any
> circumstance. "To thine self be true!"

But yet the Python interpreter has no problem with:

"""
Simple definition of a Coupler
"""

from math import sqrt


class Point:

    def __init__(me, x = 0, y = 0, z = 0):
        me.x = x
        me.y = y
        me.z = z

    def __repr__(me):
        return 'Point at (%s, %s, %s)' % (me.x, me.y, me.z)

    def distance(me, other):
        return ( (me.x - other.x)**2 +
                 (me.y - other.y)**2 +
                 (me.z - other.z)**2 )**.5

# globals:
A = Point(1,0,0)
B = Point(0,1,0)
C = Point(-1,0,0)
D = Point(0,-1,0)
E = Point(0,0,sqrt(2)/2)
F = Point(0,0,-sqrt(2)/2)

class Coupler:

    def __init__(me):
        me.A = A
        me.B = B
        me.C = C
        me.D = D
        me.E = E
        me.F = F
        me.volume = 1

    def rotate(me):
        # to be implemented
        pass

    def __repr__(me):
        return 'Coupler (%s, %s, %s, %s, %s, %s)' % \
               (me.A, me.B, me.C, me.D, me.E, me.F)

>
> > David Goodger was good on this in his 'Idiomatic Python'
> > at OSCON 2007 [2]:
> >
> > If your object is an iterable (i.e. has a "duck face" (which is
> > like being a "duck type" but sounds more like "interface"))
> > then address as such, as in in 'for myvar in self.__dict__',
> > and not using has_key() or some such more specialcase
> > form.
>
> Huh? I'm affraid I don't follow this. If my object (meaning self?) is
> iterable, I doubt that I intend to iterate through its namespace.  If the
> point is simply not to use keys() as the iterable sequence for a dictionary,
> whether it's self.__dict__ or any other dictionary,  that I get.

Yeah, second point -- treating __dict__ like any other dictionary,
not using keys() plus just 'if foo in bar:' not 'if bar.has_key(foo):'

> > In this same spirit (aha! another one), we just go with 'self'
> > at the end of the day.
> >
>
> And all is right with the world.
>
> --John

I like using first person pronouns for 'self' in some segments because
it helps with the OO thinking.

It's not just 'is a' or 'has a' that we want to inspire, but 'am a'.

Like Bottom in Midsummer Night's Dream:  'I am a wall'.

Kirby

From john.zelle at wartburg.edu  Tue Aug 14 16:14:03 2007
From: john.zelle at wartburg.edu (John Zelle)
Date: Tue, 14 Aug 2007 09:14:03 -0500
Subject: [Edu-sig] spinning 'self'
In-Reply-To: <f604188c0708132130j2c5e5c72y2b4deb1f6ce5e553@mail.gmail.com>
References: <f604188c0708131343x295fc047md1125f2cab373143@mail.gmail.com>
	<200708131933.15807.john.zelle@wartburg.edu>
	<f604188c0708132130j2c5e5c72y2b4deb1f6ce5e553@mail.gmail.com>
Message-ID: <200708140914.03281.john.zelle@wartburg.edu>

On Monday 13 August 2007 11:30 pm, kirby urner wrote:
> On 8/13/07, John Zelle <john.zelle at wartburg.edu> wrote:
> > I would quibble about self not doing any work (you need it to access its
> > attributes), but I understand the point you are making. Again, though
> > this makes things seem a bit more mysterious than they really are. The
> > self parameter is a placeholder in the exact same sense that all formal
> > parameters are place holders for objects that are provided at call time.
> > The self parameter has no 'specialness' in this regard.
>
> Yes, I agree.  What's special about 'self' is simply what you mentioned
> above:  it gets passed "silently" and you need take special care to have
> a variable (usually 'self') ready for it as the first parameter of your
> method definition -- but then don't mention it when you call in (' self '
> is "implied" -- what makes it special).
>

But this is exactly my point. Self is _not_ passed silently. The actual 
parameter is right there in the call: obj.someMethod(actual1, actual2). obj 
_is_ the parameter. The only difference is that it's not inside the parens 
when the call is made (unless you use someClass.someMethod(obj, actual1, 
actual2, which makes my point even more directly). Self in the method 
definition is not at all special. Rather it's the calling syntax that's 
different. And the simplest explanation for the different form of  call 
syntax the fact that it's dispatching a method based on the type of obj 
(although I wouldn't use that terminology for beginning students). 

> But the purpose of 'self' comes into its own when you have a million
> 'selves' (or just ten) all instantiated from the very same class
> definition.

> Then we start to appreciate how each of those million has its own
> state, its own anchor in memory, thanks to 'self' (or whatever) and in
> turn self.__dict__.

OK, so objects have state. That's an important part of OO, but again, I don't 
see any particular tie to the "magic" of self. Perhaps I'm reading too much 
into what you are saying, but it seems like you are somehow trying to tie OO 
into some "deep" truth or grand insight into the notion of self, perhaps in 
the sense of self-reference and self-knowledge. At least that's what your 
musing on the different points of view presented by renaming self seem to 
suggest to me. I would emphasize quite the opposite: The _mechanisms_ of OO 
are quite straightforward, mundane actually, and not at all amazing or 
mysterious.

Again, I might just be reading too much into what you are saying, as I 
personally have always been fascinated with the human sense of self (The 
mind's "I" as Hofstadter and Dennet put it). Having just read Hofstader's "I 
am a Strange Loop,"  I find myself thinking about these issues perhaps a bit 
too much.

> There's nothing much else to distinguish two objects of the same type.
> ' self ' objectifies objects, and as such isn't really called upon to play
> its role until an object is instantiated (i.e. gains a self).
>
> I forgot to suggest 'I' (capital 'eye') as an interim possibility (in
> addition to candidates ' this ', ' ghost ', ' me ') though of course that's
> hard to decipher in ASCII (looks just like Number One).

Hofstadter and others point out that there is some strange entanglement or 
loop going on when we use the terms like  "I" or "me." That's the kind of 
conundrum I'd like not to have my students thinking is part of OO. Again, the 
mechanisms of OO are quite pedestrian, even though we _can_ use them to build 
amazing abstraction. I say leave contemplation of "self" to philosophy and AI 
classes. For me, Python's self is just the conventional name of the first 
formal parameter of a method. Using the same name all the time allows anyone 
reading even the smallest snippet of my code to know that I am accessing an 
attribute of the object that caused the method lookup. There is nothing deep, 
mysterious, magical, or even difficult, about it. Let's not give the 
impression that there is.

--John

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

From kirby.urner at gmail.com  Tue Aug 14 19:14:19 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Tue, 14 Aug 2007 10:14:19 -0700
Subject: [Edu-sig] spinning 'self'
In-Reply-To: <200708140914.03281.john.zelle@wartburg.edu>
References: <f604188c0708131343x295fc047md1125f2cab373143@mail.gmail.com>
	<200708131933.15807.john.zelle@wartburg.edu>
	<f604188c0708132130j2c5e5c72y2b4deb1f6ce5e553@mail.gmail.com>
	<200708140914.03281.john.zelle@wartburg.edu>
Message-ID: <f604188c0708141014p4354deb1m46a3d30eb85dac2@mail.gmail.com>

[ after two consecutive trips to Winterhaven as younger daughter,
like older sis, is studying theater but forgot her script...  -- KU ]

> > Yes, I agree.  What's special about 'self' is simply what you mentioned
> > above:  it gets passed "silently" and you need take special care to have
> > a variable (usually 'self') ready for it as the first parameter of your
> > method definition -- but then don't mention it when you call in (' self '
> > is "implied" -- what makes it special).
> >
>
> But this is exactly my point. Self is _not_ passed silently. The actual
> parameter is right there in the call: obj.someMethod(actual1, actual2). obj
> _is_ the parameter. The only difference is that it's not inside the parens
> when the call is made (unless you use someClass.someMethod(obj, actual1,
> actual2, which makes my point even more directly). Self in the method
> definition is not at all special. Rather it's the calling syntax that's
> different. And the simplest explanation for the different form of  call
> syntax the fact that it's dispatching a method based on the type of obj
> (although I wouldn't use that terminology for beginning students).

Well, I'd say 'self' is loudly whispered then, and caution against calling
the object in noun.verb(params) a "parameter" of said expression.  To
the interpreter maybe, but not to verb( ).  Or if it is a param, then it's
"special" simply for *not* being listed between the parens.

I typically teach seeing foo( ) as "a thing with a mouth" as "( )" has the
appearance of "lips turned sideways" (emoticon style) and their function
*is* actually to signal intake of the contents, to some internal scope
(a local namespace).

But why not see foo( ) as "a thing with an ear" instead?  Makes sense.

We'll maybe get to nose later.

NOTE:  I don't teach that return returns poop except in purposely scatalogical
treatments (per my Europython 2007 slides).  No, a function returns the fruits
of its labor, its work, which one can objectify and return as a gift
(I hear the
Freudians cackle), as a referent (the return object).  The "landscape" wherein
all this "work" is getting done we call "memory" or sometimes "the heap"
(just think of a junk pile).

So I see 'obj.name(params):' as a case of obj "loudly whispering" its
identity into its own ear, where there's suddenly a parameter waiting
to catch it, even where the *caller* had no clue (it's what "heard the call"
that "already knew"):

>>> class Foo:

	def __init__(self, name):
		self.name = name
	def checkid(self, other):
		return id(self) == id(other)

	
>>> myguy = Foo('Joe')
>>> myguy.checkid(myguy)  # caller needn't know self id, cuz myguy
already knows it
True
>>> mygal = Foo('Jane')
>>> mygal.checkid(myguy)  # mygal knows she's not myguy, despite being same type
False

> > But the purpose of 'self' comes into its own when you have a million
> > 'selves' (or just ten) all instantiated from the very same class
> > definition.
>
> > Then we start to appreciate how each of those million has its own
> > state, its own anchor in memory, thanks to 'self' (or whatever) and in
> > turn self.__dict__.
>
> OK, so objects have state. That's an important part of OO, but again, I don't
> see any particular tie to the "magic" of self. Perhaps I'm reading too much
> into what you are saying, but it seems like you are somehow trying to tie OO
> into some "deep" truth or grand insight into the notion of self, perhaps in
> the sense of self-reference and self-knowledge. At least that's what your
> musing on the different points of view presented by renaming self seem to
> suggest to me. I would emphasize quite the opposite: The _mechanisms_ of OO
> are quite straightforward, mundane actually, and not at all amazing or
> mysterious.

I think I'm going for a mark between these extremes.  I get students deeply
suspicious of engineering in general, cynical about engineers as cold fish
who build ugly killing machines (Quaker schools remember).

They already know we see humans in OO terms in games like Sims, so
there's no use denying it.  Sims is easy to diss if you think it teaches
that humans are mere automatons, predetermined by fate, mere
automatons and yadda yadda (the usual BS).

With Python, I want to be able to say, kind of as you do, "look, very
transparent, nothing up the sleeves, quite unremarkable, shallow (not
murky) by design".

But I also want them to feel safe modeling themselves as "things with
backbones" (where __ribs__ come together) i.e. it's not demeaning or
profane to model humans, including one's self, in these simple computer
language comic strips we call "programs" (scripts).

That feared determinism isn't really there, because everything ultimately
faces outward into userspace anyway (no namespace is ultimately
completely private or how do we justify calling it a namespace, even
to ourselves?)).

Userspace where the *real* humans are, and it's not our business to
pretend we're isomorphic to them (this is not an AI project).  We're
"cave paintings," "homomorphisms," "analogies" -- very primitive, but
do valuable and intelligible work nonetheless.  "We" being "we computer
programs" in this paragraph.

> Again, I might just be reading too much into what you are saying, as I
> personally have always been fascinated with the human sense of self (The
> mind's "I" as Hofstadter and Dennet put it). Having just read Hofstader's "I
> am a Strange Loop,"  I find myself thinking about these issues perhaps a bit
> too much.

Part of this fits into what I call "empathic programming" where we encourage
budding engineers to develop kinesthetic models of hydropower dams and
such.

"I am a dam" means feeling that restrained water, that emanating electricity,
all those frustrated fish.

They know about this in Holland:  a stressed dike is stressful.

This isn't to "romanticize" engineering (although maybe it does some, as the
Romans were reputedly good at engineering, so were likely empathic, more
regarding their aqueducts and machines than their fellow humans though,
especially slaves -- personality attributes still all too prevalent).

OO fits in with this ability of pretty much anything to "have a self" (that's
part of the analogy:  the type or class is what's general to all, whereas
"having a self" means "personalized" or "individuated" in some way).

> > There's nothing much else to distinguish two objects of the same type.
> > ' self ' objectifies objects, and as such isn't really called upon to play
> > its role until an object is instantiated (i.e. gains a self).
> >
> > I forgot to suggest 'I' (capital 'eye') as an interim possibility (in
> > addition to candidates ' this ', ' ghost ', ' me ') though of course that's
> > hard to decipher in ASCII (looks just like Number One).
>
> Hofstadter and others point out that there is some strange entanglement or
> loop going on when we use the terms like  "I" or "me." That's the kind of
> conundrum I'd like not to have my students thinking is part of OO.

Right.  Python isn't so murky.

> Again, the
> mechanisms of OO are quite pedestrian, even though we _can_ use them to build
> amazing abstraction. I say leave contemplation of "self" to philosophy and AI
> classes. For me, Python's self is just the conventional name of the first
> formal parameter of a method. Using the same name all the time allows anyone
> reading even the smallest snippet of my code to know that I am accessing an
> attribute of the object that caused the method lookup. There is nothing deep,
> mysterious, magical, or even difficult, about it. Let's not give the
> impression that there is.
>
> --John

For me, the OO model comes into better focus when I allow it to take over the
world at least interimly (while I'm programming), such that
"everything (including
me) is an object".

I'm putting a lot of emphasis on 'self' in first person terms, including other
Unicode symbols, because I'm trying to recruit new users, whatever their
pre-existing philosophies (I make few presumptions), into checking out and
using our OO mirror.

Kirby

From dragoncow2 at gmail.com  Tue Aug 14 21:54:50 2007
From: dragoncow2 at gmail.com (Nicholas Wheeler)
Date: Tue, 14 Aug 2007 15:54:50 -0400
Subject: [Edu-sig] Open Minds Conference
Message-ID: <9047620b0708141254s42676895j7da55d499793b78d@mail.gmail.com>

This isn't very python related, but it is open source software in
education related....I'm guessing some of you on this list would love
to speak as a presenter at this conference on the work you do using
open source tools in education.....

http://openmindsconference.org

-- 
Nicholas Wheeler
Systems Administrator
Development InfoStructure

From kirby.urner at gmail.com  Tue Aug 14 23:23:27 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Tue, 14 Aug 2007 14:23:27 -0700
Subject: [Edu-sig] Fwd:  spinning 'self'
In-Reply-To: <f604188c0708141014p4354deb1m46a3d30eb85dac2@mail.gmail.com>
References: <f604188c0708131343x295fc047md1125f2cab373143@mail.gmail.com>
	<200708131933.15807.john.zelle@wartburg.edu>
	<f604188c0708132130j2c5e5c72y2b4deb1f6ce5e553@mail.gmail.com>
	<200708140914.03281.john.zelle@wartburg.edu>
	<f604188c0708141014p4354deb1m46a3d30eb85dac2@mail.gmail.com>
Message-ID: <f604188c0708141423t24a21970j333e7ca20a8dcbc0@mail.gmail.com>

> I'm putting a lot of emphasis on 'self' in first person terms, including other
> Unicode symbols, because I'm trying to recruit new users, whatever their
> pre-existing philosophies (I make few presumptions), into checking out and
> using our OO mirror.
>
> Kirby
>

To put it another way, more succinctly, "to objectify" and "to dehumanize"
have become roughly synonymous sins in many a lexicon, and would-be
Pythonistas may bet turned off when they see that little 'self' floating around
amidst all the rest of the machinery, confirming their worst fears about
geek-speak and engineers always  "objectifying" everything (so *that's*
how my world got so ugly!  I can blame *them*!).

Rather than give in to this prejudice, a form of bigotry against those using
OO languages, I say we take that bull by the horns and show how
"objectifying everything" is helping us responsibly model, visualize and
control a lot of important infrastructure, and that our goals are to humanize,
to empathize, to build stuff that improves living standards, makes sense.

And yes, we objectify humans as well, how could we not, and keep our
models relevant?  Think of comic books (mirrors of reality, sequential),
except executing, doing work, making our infrastructure more secure,
more reliable.

Kirby

From heistooheavy at yahoo.com  Wed Aug 15 16:04:02 2007
From: heistooheavy at yahoo.com (Richard Guenther)
Date: Wed, 15 Aug 2007 07:04:02 -0700 (PDT)
Subject: [Edu-sig] Using IDLE with students
Message-ID: <691594.15055.qm@web63312.mail.re1.yahoo.com>

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.

Thanks,
Richard





      ____________________________________________________________________________________
Shape Yahoo! in your own image.  Join our Network Research Panel today!   http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20070815/d8dad1eb/attachment.htm 

From john.zelle at wartburg.edu  Wed Aug 15 17:13:32 2007
From: john.zelle at wartburg.edu (John Zelle)
Date: Wed, 15 Aug 2007 10:13:32 -0500
Subject: [Edu-sig] Using IDLE with students
In-Reply-To: <691594.15055.qm@web63312.mail.re1.yahoo.com>
References: <691594.15055.qm@web63312.mail.re1.yahoo.com>
Message-ID: <200708151013.33026.john.zelle@wartburg.edu>



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  

From ajudkis at verizon.net  Thu Aug 16 15:01:26 2007
From: ajudkis at verizon.net (Andy Judkis)
Date: Thu, 16 Aug 2007 09:01:26 -0400
Subject: [Edu-sig] Using IDLE with students
References: <mailman.9.1187258406.19515.edu-sig@python.org>
Message-ID: <000801c7e005$8f9e8f20$0601a8c0@Gandalf>

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

I run into this a lot, and I find that it's very very difficult to explain 
what's going on to kids who are just getting their feet wet.

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

The problem that I run into is that the livewires graphics package doesn't 
behave properly unless the -n is used.  Here's a link with some background: 
http://mail.python.org/pipermail/edu-sig/2005-November/005583.html
I think I've run into other packages that also have problems but livewires 
is the one I'm sure about.  This has been a real problem for me.

Andy


From ajudkis at verizon.net  Thu Aug 16 15:03:55 2007
From: ajudkis at verizon.net (Andy Judkis)
Date: Thu, 16 Aug 2007 09:03:55 -0400
Subject: [Edu-sig] Using IDLE with students (Richard Guenther)
References: <mailman.9.1187258406.19515.edu-sig@python.org>
Message-ID: <000a01c7e005$e7467080$0601a8c0@Gandalf>

To follow up on my post of a minute ago, turtle graphics is also screwed up 
unless you run with -n. . .
- Andy 


From kirby.urner at gmail.com  Thu Aug 16 16:44:52 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 16 Aug 2007 07:44:52 -0700
Subject: [Edu-sig] Using IDLE with students
In-Reply-To: <000801c7e005$8f9e8f20$0601a8c0@Gandalf>
References: <mailman.9.1187258406.19515.edu-sig@python.org>
	<000801c7e005$8f9e8f20$0601a8c0@Gandalf>
Message-ID: <f604188c0708160744t1d8180fdt8b013ddbdf224eee@mail.gmail.com>

The subprocess idea is important I agree.

Also, psychologically, we would like students to see putting code in
a module as "canning for later" i.e. there's a strong prejudice against
thinking of the current session namespace as containing anything
vital to the operations of the module.  Picturing emailing the code to
a distant user who has never once booted Python is another mental
exercise one might use.

Kirby

From heistooheavy at yahoo.com  Thu Aug 16 21:52:06 2007
From: heistooheavy at yahoo.com (Richard Guenther)
Date: Thu, 16 Aug 2007 12:52:06 -0700 (PDT)
Subject: [Edu-sig] Using IDLE with students
Message-ID: <12667.58772.qm@web63301.mail.re1.yahoo.com>

First, thanks to Andy, John and Kirby for responding--I no longer feel alone with my concerns about the namespace issues.

Is there somewhere I can read up on these issues (other than the link to the Edu-sig archives that Any mentioned)?  Before I ask I usually search the net a lot, but I didn't find much documentation on using IDLE in an educational setting.  It would be nice if there was a tutorial that would cover the "gotchas" and also give advice to people considering using IDLE.... 

Curious,
Richard


----- Original Message ----
From: kirby urner <kirby.urner at gmail.com>
To: Andy Judkis <ajudkis at verizon.net>
Cc: edu-sig at python.org
Sent: Thursday, August 16, 2007 8:44:52 AM
Subject: Re: [Edu-sig] Using IDLE with students


The subprocess idea is important I agree.

Also, psychologically, we would like students to see putting code in
a module as "canning for later" i.e. there's a strong prejudice against
thinking of the current session namespace as containing anything
vital to the operations of the module.  Picturing emailing the code to
a distant user who has never once booted Python is another mental
exercise one might use.

Kirby
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig


       
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20070816/fcd7d557/attachment.htm 

From john.zelle at wartburg.edu  Fri Aug 17 00:41:11 2007
From: john.zelle at wartburg.edu (John Zelle)
Date: Thu, 16 Aug 2007 17:41:11 -0500
Subject: [Edu-sig] Using IDLE with students
In-Reply-To: <000801c7e005$8f9e8f20$0601a8c0@Gandalf>
References: <mailman.9.1187258406.19515.edu-sig@python.org>
	<000801c7e005$8f9e8f20$0601a8c0@Gandalf>
Message-ID: <200708161741.11260.john.zelle@wartburg.edu>



On Thursday 16 August 2007 8:01 am, Andy Judkis wrote:
> > 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.
>
> I run into this a lot, and I find that it's very very difficult to explain
> what's going on to kids who are just getting their feet wet.

This is why I prefer the new IDLE running in the standard (not -n mode). It 
really is much better to keep the running script isolated in a subprocess.

<<snip>>

>
> The problem that I run into is that the livewires graphics package doesn't
> behave properly unless the -n is used.  Here's a link with some background:
> http://mail.python.org/pipermail/edu-sig/2005-November/005583.html
> I think I've run into other packages that also have problems but livewires
> is the one I'm sure about.  This has been a real problem for me.

This is also certainly true. Getting my simple graphics package (graphics.py) 
to play nicely with IDLE was a pain, and it has really taken on hit on 
efficiency as a result. I am thinking of reverting to a non-threaded version, 
but that would require IDLE to be run with the -n switch. Of course, the 
problem I'm running into now is that many folks are running IDLE with -n, and 
my graphics package does not run well in that mode (although an older version 
that I still make available runs quite well).

Another alternative is to use IDLE for as a development environment but do use 
a regular python session from a command prompt for doing interactive noodling 
around with packages that also run under Tk. There's just no good way around 
the "deuling event loops" problem in Tk (at least not on Windows, Linux is 
less of a problem).

--John

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

From heistooheavy at yahoo.com  Fri Aug 17 03:40:29 2007
From: heistooheavy at yahoo.com (Richard Guenther)
Date: Thu, 16 Aug 2007 18:40:29 -0700 (PDT)
Subject: [Edu-sig] Using IDLE with students
Message-ID: <854879.28355.qm@web63308.mail.re1.yahoo.com>

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 

From kirby.urner at gmail.com  Fri Aug 17 04:18:34 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 16 Aug 2007 19:18:34 -0700
Subject: [Edu-sig] Using IDLE with students
In-Reply-To: <854879.28355.qm@web63308.mail.re1.yahoo.com>
References: <854879.28355.qm@web63308.mail.re1.yahoo.com>
Message-ID: <f604188c0708161918l5baf63f4y314003ab6c9e3b45@mail.gmail.com>

On 8/16/07, Richard Guenther <heistooheavy at 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

From john.zelle at wartburg.edu  Fri Aug 17 05:25:12 2007
From: john.zelle at wartburg.edu (John Zelle)
Date: Thu, 16 Aug 2007 22:25:12 -0500
Subject: [Edu-sig] Using IDLE with students
In-Reply-To: <854879.28355.qm@web63308.mail.re1.yahoo.com>
References: <854879.28355.qm@web63308.mail.re1.yahoo.com>
Message-ID: <200708162225.12099.john.zelle@wartburg.edu>

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

From john.zelle at wartburg.edu  Fri Aug 17 15:45:24 2007
From: john.zelle at wartburg.edu (John Zelle)
Date: Fri, 17 Aug 2007 08:45:24 -0500
Subject: [Edu-sig] Fwd: Re:  Using IDLE with students
Message-ID: <200708170845.24499.john.zelle@wartburg.edu>

I think Richard intended this for the group. Unfortunately, due to socket 
issues on Windows, said patch has not yet been implemented.

----------  Forwarded Message  ----------

Subject: Re: [Edu-sig] Using IDLE with students
Date: Friday 17 August 2007 8:24 am
From: Richard Guenther <heistooheavy at yahoo.com>
To: John Zelle <john.zelle at wartburg.edu>

I remember installing a patch when I couldn't get IDLE to restart on my
 Windows computer.  Here's a discussion of said patch:

http://mail.python.org/pipermail/patches/2006-July/020360.html


----- Original Message ----
From: John Zelle <john.zelle at wartburg.edu>
To: Richard Guenther <heistooheavy at yahoo.com>
Cc: edu-sig at python.org; Guenther_Richard at stvrain.k12.co.us
Sent: Thursday, August 16, 2007 9:25:12 PM
Subject: Re: [Edu-sig] Using IDLE with students


<<snip>>


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

<<snip>>



_____________________________________________________________________________
_______ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket:
 mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC

-------------------------------------------------------

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

From andre.roberge at gmail.com  Tue Aug 21 03:42:04 2007
From: andre.roberge at gmail.com (Andre Roberge)
Date: Mon, 20 Aug 2007 22:42:04 -0300
Subject: [Edu-sig] Size of browser/window in school computer labs
Message-ID: <7528bcdd0708201842y307619dbt68437088737a5e7e@mail.gmail.com>

Hi everyone,

I got some feedback today from someone who was using a *much* smaller
size monitor than what I normally use and, after testing, realized
that Crunchy (as currently designed) assumes that the display is much
bigger than 800x600.  So my question is:  what size monitor is used in
*your* school/college/university's computer lab?

Andr?

From matt at schinckel.net  Tue Aug 21 06:18:24 2007
From: matt at schinckel.net (Matthew Schinckel)
Date: Tue, 21 Aug 2007 13:48:24 +0930
Subject: [Edu-sig] Size of browser/window in school computer labs
In-Reply-To: <7528bcdd0708201842y307619dbt68437088737a5e7e@mail.gmail.com>
References: <7528bcdd0708201842y307619dbt68437088737a5e7e@mail.gmail.com>
Message-ID: <2521244f0708202118p2d42e40chb3e88a96db950343@mail.gmail.com>

Varies, from 17" CRT @ 1024x768, up to 20" Widescreen (1600 ish wide)

On 21/08/07, Andre Roberge <andre.roberge at gmail.com> wrote:
> Hi everyone,
>
> I got some feedback today from someone who was using a *much* smaller
> size monitor than what I normally use and, after testing, realized
> that Crunchy (as currently designed) assumes that the display is much
> bigger than 800x600.  So my question is:  what size monitor is used in
> *your* school/college/university's computer lab?
>
> Andr?
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>


-- 
Matthew Schinckel <matt at schinckel.net>

The Feynman Problem-Solving Algorithm:
  (1) write down the problem;
  (2) think very hard;
  (3) write down the answer.

From kirby.urner at gmail.com  Tue Aug 21 20:34:42 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Tue, 21 Aug 2007 11:34:42 -0700
Subject: [Edu-sig] Urner, K.: message digest (special to edu-sig)
Message-ID: <f604188c0708211134i52208432w32add8ef7b174cc5@mail.gmail.com>

My OLPC writings have moved to Synergeo @ Yahoo, under ownership of
Ken Brown, closer to Calgary, Canada, and tracking OLPC from the
beginning:
http://worldgame.blogspot.com/2007/02/meeting-on-hawthorne.html

Pithy Python @ Math Forum, per usual, e.g.:
http://mathforum.org/kb/message.jspa?messageID=5851530&tstart=0

Otherwise, lots about MVC (Model View Controller), with this blog view
a good summary:
http://worldgame.blogspot.com/2007/08/model-view-controller-mvc.html

Kirby

From heistooheavy at yahoo.com  Wed Aug 22 02:31:13 2007
From: heistooheavy at yahoo.com (Richard Guenther)
Date: Tue, 21 Aug 2007 17:31:13 -0700 (PDT)
Subject: [Edu-sig] Size of browser/window in school computer labs
Message-ID: <637347.49349.qm@web63309.mail.re1.yahoo.com>

1024 x 768 seems to be the norm at my high school (1500 students). 

Right now I'm wrestling with our district tech dept to get them to install some OSS text editors and also Python.  I can't believe how paranoid they are....

Richard

----- Original Message ----
From: Andre Roberge <andre.roberge at gmail.com>
To: "edu-sig at python.org" <edu-sig at python.org>
Sent: Monday, August 20, 2007 7:42:04 PM
Subject: [Edu-sig] Size of browser/window in school computer labs

Hi everyone,

I got some feedback today from someone who was using a *much* smaller
size monitor than what I normally use and, after testing, realized
that Crunchy (as currently designed) assumes that the display is much
bigger than 800x600.  So my question is:  what size monitor is used in
*your* school/college/university's computer lab?

Andr?
_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig







       
____________________________________________________________________________________
Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20070821/fc1a3f8a/attachment.htm 

From jjposner at snet.net  Wed Aug 22 04:28:52 2007
From: jjposner at snet.net (John Posner)
Date: Tue, 21 Aug 2007 22:28:52 -0400
Subject: [Edu-sig] Using IDLE with students
Message-ID: <001301c7e464$2e5f5290$65bda8c0@jposner>

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

   >> I run into this a lot, and I find that it's very very difficult to
explain
   >> what's going on to kids who are just getting their feet wet.

Not denying that RESTART vs. no-RESTART is an issue, but ... if you're going
to use IDLE in no-RESTART mode, why not reinforce the functionality as a
*feature*, not avoid it as a bug. The module window works more like a macro
than a self-contained program.

For example, a lesson might investigate the Fibonacci series like this:

1. In the interactive window, set up some initial conditions:

>>> a=1
>>> b=1
>>> count=2

2. Develop the following command sequence, by trial-and-error in the
interactive window, as the way to perform one Fibonacci iteration:

>>> a,b = b,a+b
>>> count = count+1
>>> print "Fibonacci term", count, "is", b
>>> print "ratio is", 1.0*b/a

During this trial-and-error process, it's very likely that the initial
conditions will need to be reestablished a number of times.

3. Use the interactive window's command-repetition capability (move the
cursor, then press Enter) to invoke the command sequence repeatedly,
generating Fibonacci iterations.

4. Invoke "New Window" and transcribe the command sequence into the new
module window:

a,b = b,a+b
count = count+1
print "Fibonacci term", count, "is", b
print "ratio is", 1.0*b/a

5. (SLIGHT GOTCHA) You must save the contents of the new module window in a
file.

6. Repeatedly invoke "Run Module", producing more iterations in the
interactive window:

>>> 
Fibonacci term 14 is 377
ratio is 1.61802575107
>>> 
Fibonacci term 15 is 610
ratio is 1.61803713528
>>> 
Fibonacci term 16 is 987
ratio is 1.61803278689
>>> 
Fibonacci term 17 is 1597
ratio is 1.61803444782
>>> 
Fibonacci term 18 is 2584
ratio is 1.6180338134
>>> 
Fibonacci term 19 is 4181
ratio is 1.61803405573


Each time you (click in the module window and) invoke "Run Module", the four
lines of code run in the current context of the interactive window.

And more:

* Use this repeated invocation of code to motivate "for" and/or "while"
loops.

* Describe the Golden Mean and compare the (converging) computed ratios to
the actual value. To compute the actual value, you must import the "math"
module.

Best to all,
John


From delza at livingcode.org  Wed Aug 22 11:44:09 2007
From: delza at livingcode.org (Dethe Elza)
Date: Wed, 22 Aug 2007 12:44:09 +0300
Subject: [Edu-sig] Size of browser/window in school computer labs
In-Reply-To: <637347.49349.qm@web63309.mail.re1.yahoo.com>
References: <637347.49349.qm@web63309.mail.re1.yahoo.com>
Message-ID: <24d517dd0708220244i2b8d50f4o36b67cc9a2298b12@mail.gmail.com>

Not a school, but some data points for you in this world where
ultra-mobile computers (cell phones, PDAs, etc) may be out-pacing the
growth of desktops and faux-desktop laptops:

Nokia N800 web appliance (my travel computer, together with a fold-up
bluetooth keyboard it weighs about a pound, a third of that without
the keyboard): 800 x 480 resolution.  Runs PyGame nicely, has Python
2.5 as an optional install, Linux-based.

The OLPC XO is 1200 x 900 (and more amazingly, 200 DPI) and also runs
PyGame, so my N800 serves as a development platform for the XO until I
can get my hands on the real thing.

Right now I'm working on a Scratch-like environment for kids built on
top of PyGame.  My son just got an extremely powerful computer for his
7th birthday: a Nintendo DS (two screens, one touch-sensitive).  Every
game he plays, he sits down to sketch out how he would write it in
Scratch, complete with wireframes, event handling, etc.  Scratch has
been an amazing force in our house.  Right now he and his sister (who
also has a DS) are playing games against each other wirelessly,
without any support infrastructure (The DS creates its own wireless
network).  This is their world, they expect everything to be able to
be programmable, connectable, hackable (they read my copies of Make
magazine before I do and plan out their hardware projects: we'll be
building an MP3 player when we get back from vacation).

Hope all of you are well.  Greetings from Sofia, Bulgaria.

--Dethe

From andre.roberge at gmail.com  Wed Aug 22 12:37:48 2007
From: andre.roberge at gmail.com (Andre Roberge)
Date: Wed, 22 Aug 2007 07:37:48 -0300
Subject: [Edu-sig] Size of browser/window in school computer labs
In-Reply-To: <24d517dd0708220244i2b8d50f4o36b67cc9a2298b12@mail.gmail.com>
References: <637347.49349.qm@web63309.mail.re1.yahoo.com>
	<24d517dd0708220244i2b8d50f4o36b67cc9a2298b12@mail.gmail.com>
Message-ID: <7528bcdd0708220337qdb9c74k991878f7a8eff41e@mail.gmail.com>

Thanks to all of you that gave me feedback; this is very useful.   A
new version of Crunchy will soon be out - I "only" have to document
the changes in the Crunchy tutorial.   This new version will include
two new types of interpreters as option, one based on Michael Tobis's
suggestion from a few weeks ago, the other based on John Posner's
suggestion.

My over-optimistic goal is to have version 1.0 released early in
September - for use in the next school year by interested parties.  I
understand that some students working for Jeff Elkner have been
adapting "How to think like a computer scientist" as well as the
livewires modules so that they would be best making use of Crunchy.

Stay tuned...

Cheers,

Andr?

On 8/22/07, Dethe Elza <delza at livingcode.org> wrote:
> Not a school, but some data points for you in this world where
> ultra-mobile computers (cell phones, PDAs, etc) may be out-pacing the
> growth of desktops and faux-desktop laptops:
>
> Nokia N800 web appliance (my travel computer, together with a fold-up
> bluetooth keyboard it weighs about a pound, a third of that without
> the keyboard): 800 x 480 resolution.  Runs PyGame nicely, has Python
> 2.5 as an optional install, Linux-based.
>
> The OLPC XO is 1200 x 900 (and more amazingly, 200 DPI) and also runs
> PyGame, so my N800 serves as a development platform for the XO until I
> can get my hands on the real thing.
>
> Right now I'm working on a Scratch-like environment for kids built on
> top of PyGame.  My son just got an extremely powerful computer for his
> 7th birthday: a Nintendo DS (two screens, one touch-sensitive).  Every
> game he plays, he sits down to sketch out how he would write it in
> Scratch, complete with wireframes, event handling, etc.  Scratch has
> been an amazing force in our house.  Right now he and his sister (who
> also has a DS) are playing games against each other wirelessly,
> without any support infrastructure (The DS creates its own wireless
> network).  This is their world, they expect everything to be able to
> be programmable, connectable, hackable (they read my copies of Make
> magazine before I do and plan out their hardware projects: we'll be
> building an MP3 player when we get back from vacation).
>
> Hope all of you are well.  Greetings from Sofia, Bulgaria.
>
> --Dethe
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>

From kirby.urner at gmail.com  Wed Aug 22 18:35:42 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Wed, 22 Aug 2007 09:35:42 -0700
Subject: [Edu-sig] Using IDLE with students
In-Reply-To: <001301c7e464$2e5f5290$65bda8c0@jposner>
References: <001301c7e464$2e5f5290$65bda8c0@jposner>
Message-ID: <f604188c0708220935q256c6c9fq86d0c7b98a3500b4@mail.gmail.com>

> * Describe the Golden Mean and compare the (converging) computed ratios to
> the actual value. To compute the actual value, you must import the "math"
> module.
>
> Best to all,
> John

Note: you *may* import the math module, for sqrt, but remember pow is in
__builtins__ so (1 + pow(5, 0.5))/2 will work.

I liked your smooth transition from shell mode to Run in module mode
while keeping the shell open in __main__.  There's no restart in this
picture, we you're free to keep treating the module almost like a
generator in that it yields control back to the shell (after printing).

>From there it's a quick jump to explaining how a module might run
top level (as __main__), with no interactive session for a launch pad.
Put everything you'll need in the suitcase.  Just an empty hotel room
(Python interpreter + we hope Standard Library) on the other end.

Kirby

From winstonw at stratolab.com  Wed Aug 22 23:31:03 2007
From: winstonw at stratolab.com (Winston Wolff)
Date: Wed, 22 Aug 2007 17:31:03 -0400
Subject: [Edu-sig] Using MakeBot instead of IDLE
In-Reply-To: <691594.15055.qm@web63312.mail.re1.yahoo.com>
References: <691594.15055.qm@web63312.mail.re1.yahoo.com>
Message-ID: <9CBB0211-44BE-4442-A11C-96E22F75EF1A@stratolab.com>

You might like to use MakeBot (Mac and Windows, no Linux).  It's a  
very simple editor with an attached console, and you run scripts with  
the press of a button.  I use it to teach my students and it's great  
because of it's simplicity.  I don't have to spend any time teaching  
around the quirks of IDLE.  I just say "type this in and press run"

	http://stratolab.com/misc/makebot/

-Winston



Winston Wolff
winstonw at stratolab.com
(646) 827-2242

------------------------------------------------------------------------ 
--
Stratolab - video game courses for kids in new york - http:// 
stratolab.com



On Aug 15, 2007, at 10: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.
>
> Thanks,
> Richard
>
>
> Moody friends. Drama queens. Your life? Nope! - their life, your  
> story.
> Play Sims Stories at Yahoo! Games.
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig


From winstonw at stratolab.com  Wed Aug 22 23:35:19 2007
From: winstonw at stratolab.com (Winston Wolff)
Date: Wed, 22 Aug 2007 17:35:19 -0400
Subject: [Edu-sig] Scratch interface for Python,
	and network programming games.
In-Reply-To: <24d517dd0708220244i2b8d50f4o36b67cc9a2298b12@mail.gmail.com>
References: <637347.49349.qm@web63309.mail.re1.yahoo.com>
	<24d517dd0708220244i2b8d50f4o36b67cc9a2298b12@mail.gmail.com>
Message-ID: <882FE2ED-03A5-4790-A3C6-DE93DFFB1B14@stratolab.com>

Hi Dethe-

I have been thinking of exactly the same thing--a Scratch type  
environment for Python.  And I've also purchased a Nintendo DS  
development kit, hoping to make a Python to Nintendo DS development  
system.  Haven't had time to work on it though with my summer  
classes.  I should have more time in the fall, perhaps we can  
collaborate?

My biggest interest on the Scratch/Python angle right now is to  
develop some team programming games.  I.e. you write a program using  
Python raw or Python via a Scratch interface for beginners, and then  
you throw your program into the ring via the network and have it  
compete against other students.



Winston Wolff
winstonw at stratolab.com
(646) 827-2242

------------------------------------------------------------------------ 
--
Stratolab - video game courses for kids in new york - http:// 
stratolab.com



On Aug 22, 2007, at 5:44 AM, Dethe Elza wrote:

> Not a school, but some data points for you in this world where
> ultra-mobile computers (cell phones, PDAs, etc) may be out-pacing the
> growth of desktops and faux-desktop laptops:
>
> Nokia N800 web appliance (my travel computer, together with a fold-up
> bluetooth keyboard it weighs about a pound, a third of that without
> the keyboard): 800 x 480 resolution.  Runs PyGame nicely, has Python
> 2.5 as an optional install, Linux-based.
>
> The OLPC XO is 1200 x 900 (and more amazingly, 200 DPI) and also runs
> PyGame, so my N800 serves as a development platform for the XO until I
> can get my hands on the real thing.
>
> Right now I'm working on a Scratch-like environment for kids built on
> top of PyGame.  My son just got an extremely powerful computer for his
> 7th birthday: a Nintendo DS (two screens, one touch-sensitive).  Every
> game he plays, he sits down to sketch out how he would write it in
> Scratch, complete with wireframes, event handling, etc.  Scratch has
> been an amazing force in our house.  Right now he and his sister (who
> also has a DS) are playing games against each other wirelessly,
> without any support infrastructure (The DS creates its own wireless
> network).  This is their world, they expect everything to be able to
> be programmable, connectable, hackable (they read my copies of Make
> magazine before I do and plan out their hardware projects: we'll be
> building an MP3 player when we get back from vacation).
>
> Hope all of you are well.  Greetings from Sofia, Bulgaria.
>
> --Dethe
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig


From delza at livingcode.org  Thu Aug 23 09:11:58 2007
From: delza at livingcode.org (Dethe Elza)
Date: Thu, 23 Aug 2007 10:11:58 +0300
Subject: [Edu-sig] Scratch interface for Python,
	and network programming games.
In-Reply-To: <882FE2ED-03A5-4790-A3C6-DE93DFFB1B14@stratolab.com>
References: <637347.49349.qm@web63309.mail.re1.yahoo.com>
	<24d517dd0708220244i2b8d50f4o36b67cc9a2298b12@mail.gmail.com>
	<882FE2ED-03A5-4790-A3C6-DE93DFFB1B14@stratolab.com>
Message-ID: <24d517dd0708230011r56468266pd74db7897d0ebbe8@mail.gmail.com>

Hi Winston,

> I have been thinking of exactly the same thing--a Scratch type
> environment for Python.  And I've also purchased a Nintendo DS
> development kit, hoping to make a Python to Nintendo DS development
> system.  Haven't had time to work on it though with my summer
> classes.  I should have more time in the fall, perhaps we can
> collaborate?

It's cool that you're interested in collaborating on Scratch for
Python (or whatever we end up calling it).  I'd love that.  Right now
it's not easy for me to set it up, but I can when I return to
Vancouver in mid-September.  My internet access is limited right now,
and the N800 I'm developing on isn't on the net.  Do you have any
preferences between SVN (probably hosted at Google) vs. distributed
VCS like Bazaar?

The Nintendo development system has tempted me, but then I see the
Lego Mindstorms sitting around waiting to be programmed, and the
Roomba that I've utterly failed to hack (although it does make an
excellent vacuum cleaner, we use it for that all the time ;-) .  So
I've restrained myself so far, but if you get PyGame working on it,
I'll be there in a flash.

> My biggest interest on the Scratch/Python angle right now is to
> develop some team programming games.  I.e. you write a program using
> Python raw or Python via a Scratch interface for beginners, and then
> you throw your program into the ring via the network and have it
> compete against other students.

This sounds very interesting, and something my kids could really get
into.  Do you have more details about what kind of programs they would
compete with?

> Winston Wolff
> winstonw at stratolab.com
> (646) 827-2242
>
> ------------------------------------------------------------------------
> --
> Stratolab - video game courses for kids in new york - http://
> stratolab.com

--Dethe

From mtobis at gmail.com  Thu Aug 23 19:29:37 2007
From: mtobis at gmail.com (Michael Tobis)
Date: Thu, 23 Aug 2007 12:29:37 -0500
Subject: [Edu-sig] Scratch interface for Python,
	and network programming games.
In-Reply-To: <24d517dd0708230011r56468266pd74db7897d0ebbe8@mail.gmail.com>
References: <637347.49349.qm@web63309.mail.re1.yahoo.com>
	<24d517dd0708220244i2b8d50f4o36b67cc9a2298b12@mail.gmail.com>
	<882FE2ED-03A5-4790-A3C6-DE93DFFB1B14@stratolab.com>
	<24d517dd0708230011r56468266pd74db7897d0ebbe8@mail.gmail.com>
Message-ID: <c3aa55550708231029s593077abq6677f4337bc6ff6e@mail.gmail.com>

It's interesting you mention roomba in the same posting.

I had the same idea, and ithe game I have in mind is explicitly about
virtual roombas!

We would provide a virtual world in which different colored vaccum
cleaners could suck up dirt off a virtual carpet or bonk each other
off course. Each player would control a few disks (e.g., I have 3 red
roombas and you have 3 green ones); many variations of the world
physics and game rules are possible. The players would provide
strategy code for their roombas; we would provide world physics. A
fast moving disk would pick up a smaller percentage of the available
dirt but be better at deflecting opposing disks. Whichever team had
picked up the most dirt within, say, a minute, would win.

I am also thrilled by the idea of Scratch in Python, but this brings
us up against the limitations of the web. The fact that Scratch apps
can be shared on the web is a crucial advantage. Could Python Scratch
be targeted to Jython to provide sharability?

mt

From delza at livingcode.org  Thu Aug 23 19:51:25 2007
From: delza at livingcode.org (Dethe Elza)
Date: Thu, 23 Aug 2007 20:51:25 +0300
Subject: [Edu-sig] Scratch interface for Python,
	and network programming games.
In-Reply-To: <c3aa55550708231029s593077abq6677f4337bc6ff6e@mail.gmail.com>
References: <637347.49349.qm@web63309.mail.re1.yahoo.com>
	<24d517dd0708220244i2b8d50f4o36b67cc9a2298b12@mail.gmail.com>
	<882FE2ED-03A5-4790-A3C6-DE93DFFB1B14@stratolab.com>
	<24d517dd0708230011r56468266pd74db7897d0ebbe8@mail.gmail.com>
	<c3aa55550708231029s593077abq6677f4337bc6ff6e@mail.gmail.com>
Message-ID: <24d517dd0708231051t79fd5216td3b0c2acec85e9a0@mail.gmail.com>

Michael Tobis wrote:

> I am also thrilled by the idea of Scratch in Python, but this brings
> us up against the limitations of the web. The fact that Scratch apps
> can be shared on the web is a crucial advantage. Could Python Scratch
> be targeted to Jython to provide sharability?

To Jython, or if we keep to the limited functionality of Scratch, to
Flash, which would be more self-contained (and faster) than Java.
Another advantage to using PyGame is that we could provide export to
self-contained executables, to run the games on Mac, Windows, or
Linux.  Scratch itself has not yet been ported to Linux (sad, since it
is built on top of Squeak, which runs fine on Linux), keeping it off
of platforms such as XO and my trusty N800.

I like the idea of virtual Roombas, especially as a leaping-off point.
 I can imagine kids costomizing their Roombas: spinning blades, laser
turrets, even Steampunk Roombas.  Once they have a platform to build
on, anything is possible.

Lots of interesting ideas here.  Anyone else interested in this project?

--Dethe

From kirby.urner at gmail.com  Thu Aug 23 21:39:31 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 23 Aug 2007 12:39:31 -0700
Subject: [Edu-sig] Rich Data Streams
Message-ID: <f604188c0708231239n44cb4850if73d640d3a96a239@mail.gmail.com>

The idea of rich data structures was to take advantage of the
Internet by providing students with more meaningful precoded
data through which to plow.

Examples:

*  all the bones in the body as a tree structure (with some fancy
networking among skull bones)

* GIS info (I posted cities.xml from Winterhaven)

* the eight planets of our solar system, plus Pluto and Iris
(the latter owned by CBS (smile)).

The idea of a rich data stream anticipates Python 3's strong
powers around data bitting (new bit type), which'll make OO
dissection of IPv6 packets (legacy IPv4 packets) a cinch.

Kids'll groove in their ability to really dissect what's going on
over the wire (sniffed from the ether or whatever).

Rather than encourage too much interloping on neighbors' comm
channels (a favorite hacker pass time I realize), we need canned
data streams of a simplified "cave painting" nature, with known
solutions.

Like it'll be a goal of the packetsniffer.py package to zip through
these canned packets at high (enough) speed, and to spit back
reports on whether they're tcp or udp, used by which flavored
protocols and so on (you need ideas about protocol if you hope
to reconstruct the payload, for all but the simplest of containers).

Students will grow to understand tcp/ip by reading packetsniffer's
deliberately *non*-obfuscated source code.  What a relief to see
it all in Python, vs. staring at low-level C structs all the time.
Most would die of boredom before getting there.  Python keeps
it less boring.

I'm aware that the Python Community hasn't waited for Python 3
before beginning work in this genre.

Python has some of the more sophisticated networking tools
around, including flagship peer to peer bittorrent in wx.

Python is *truly* an effective language, which is why certain unnamed
schools of low standards prefer students to concentrate on maybe
Visual Basic or Java.  The former is toothless enough (minus the
ActiveX add-ons), and the latter is difficult enough, that relatively few
in those two camps are as likely to experience the free flowing and
comprehensible style we Pythoneers simply take for granted.

Tough luck for them, and best wishes on some next iteration.**

Kirby

** of course this rhetoric is full of false dichotomies, I realize.
Many of us who code in Python likewise enjoy Java and VB.NET
sometimes, or C# or whatever.  I came to Python via Java from
xBase (which I still use), and before that APL (which got me
spoiled on always wanting REPL).  So to heap scorn on BASIC,
which I'm not doing, is really ahistorical anyway.  There wasn't
any Python way back then, especially not on the ROM chip when
you booted the PC.  However, I *do* still oppose this misguided
"Python: the new BASIC" meme.  I think that's stupid, as it
overlooks Python's way stronger potential owing to its much
higher level of design sophistication.  "Python ain't yer
grandfather's BASIC" is the slogan I'd prefer.  Too bad JavaScript
is so poorly named, as it'd be a better runner up to Python
(because of the DOM) than most 2nd banana languages.

From jeff at taupro.com  Fri Aug 24 00:43:23 2007
From: jeff at taupro.com (Jeff Rush)
Date: Thu, 23 Aug 2007 17:43:23 -0500
Subject: [Edu-sig] Rich Data Streams
In-Reply-To: <f604188c0708231239n44cb4850if73d640d3a96a239@mail.gmail.com>
References: <f604188c0708231239n44cb4850if73d640d3a96a239@mail.gmail.com>
Message-ID: <46CE0D8B.3020800@taupro.com>

kirby urner wrote:
> The idea of rich data structures was to take advantage of the
> Internet by providing students with more meaningful precoded
> data through which to plow.
> 
> Examples:
> 
> *  all the bones in the body as a tree structure (with some fancy
> networking among skull bones)
> 
> * GIS info (I posted cities.xml from Winterhaven)
> 
> * the eight planets of our solar system, plus Pluto and Iris
> (the latter owned by CBS (smile)).
> 
> The idea of a rich data stream anticipates Python 3's strong
> powers around data bitting (new bit type), which'll make OO
> dissection of IPv6 packets (legacy IPv4 packets) a cinch.

Kirby, I've seen your posts re building up a reusable set of data for teaching
before, and I think it is a good idea.  Where are you collecting and making
this information available?  It seems like a single project under source
control would allow others to utilize and contribute to such a stockpile,
piece by piece.

-Jeff

From kirby.urner at gmail.com  Fri Aug 24 01:09:37 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 23 Aug 2007 16:09:37 -0700
Subject: [Edu-sig] Rich Data Streams
In-Reply-To: <46CE0D8B.3020800@taupro.com>
References: <f604188c0708231239n44cb4850if73d640d3a96a239@mail.gmail.com>
	<46CE0D8B.3020800@taupro.com>
Message-ID: <f604188c0708231609t48ea9e27ia56f014f7318dbec@mail.gmail.com>

On 8/23/07, Jeff Rush <jeff at taupro.com> wrote:

> Kirby, I've seen your posts re building up a reusable set of data for teaching
> before, and I think it is a good idea.  Where are you collecting and making
> this information available?  It seems like a single project under source
> control would allow others to utilize and contribute to such a stockpile,
> piece by piece.
>
> -Jeff
>

I'm more just into upholding edu-sig's reputation as a source of
great ideas.  Rich Data Structures & Streams, you saw it here
first.

Kirby

From mpaul at bhusd.k12.ca.us  Fri Aug 24 01:35:30 2007
From: mpaul at bhusd.k12.ca.us (Michel Paul)
Date: Thu, 23 Aug 2007 16:35:30 -0700
Subject: [Edu-sig] modeling the rational numbers
References: <f604188c0708231239n44cb4850if73d640d3a96a239@mail.gmail.com>
Message-ID: <3D142BFDEDAC8D46A40F4EA0B36D1F3501888508@MAIL.bhusd.k12.ca.us>

Here is a little summer project I'd like to share.  

This is simply a Python module that blends text and code.  The idea is that a student can read the file just like any text file, but they can simultaneously interact with its code in the Shell.  I think this is a very useful and simple format.

The goal here is to create something that would be of value to both math and programming students.  A math student wouldn't have to understand the code in order to use it.  However, it's all there if they want to inspect it.  Hopefully an interested reader would end up learning both some math and some programming.

In the beginning I refer to using tuples to represent fractions and Cartesian points.  That is because I had created some earlier lessons where I was trying to keep things minimal.  However, in this lesson it makes a lot of sense to introduce a simple Rational class.  I only implement __init__ and __repr__, making it kind of a fancy struct.  With just that very simple class and a function to generate the mediant of two rationals, you can generate ALL non-negative rationals!  It's really very interesting.  

If used in a programming class, we would of course then go back and fill in the Rational class with __add__, __mul__, etc.  But in the context of a typical math class where many of the students aren't sure they even want to learn programming at all, I think this kind of an approach could be useful.  They could use the code as is, and, who knows, they might even be intrigued to try to understand it?

I've noticed that LOTS of students don't really have a good grasp of the rationals at all, and that's not good.  It is only by means of the rational that you can articulate the irrational.  I just recently discovered Farey sequences and Ford circles.  These things have been around now for awhile, but I don't think I've ever seen them discussed in a high school math text!  

I appreciate any suggestions, especially along programming lines, that people may have.

Thanks,

- Michel Paul



-------------- next part --------------
A non-text attachment was scrubbed...
Name: modeling rational numbers.py
Type: application/octet-stream
Size: 6867 bytes
Desc: modeling rational numbers.py
Url : http://mail.python.org/pipermail/edu-sig/attachments/20070823/7fdcff85/attachment-0001.obj 

From andre.roberge at gmail.com  Fri Aug 24 02:16:27 2007
From: andre.roberge at gmail.com (Andre Roberge)
Date: Thu, 23 Aug 2007 21:16:27 -0300
Subject: [Edu-sig] modeling the rational numbers
In-Reply-To: <3D142BFDEDAC8D46A40F4EA0B36D1F3501888508@MAIL.bhusd.k12.ca.us>
References: <f604188c0708231239n44cb4850if73d640d3a96a239@mail.gmail.com>
	<3D142BFDEDAC8D46A40F4EA0B36D1F3501888508@MAIL.bhusd.k12.ca.us>
Message-ID: <7528bcdd0708231716k142755b3gc4c2172f52ce4006@mail.gmail.com>

On 8/23/07, Michel Paul <mpaul at bhusd.k12.ca.us> wrote:
> Here is a little summer project I'd like to share.
>
> This is simply a Python module that blends text and code.

Have you looked at Crunchy?   (http://code.google.com/p/crunchy)

Crunchy allows you to "blend"  (to use your expression) html text and
Python code.  You can view the file in your browser and interact
(execute the code) in it.

Quoting from your file:
===
If you arrange this window and the Shell side by side, you will be able to
easily test the code you are studying as you read through the lesson.
===
Crunchy makes the file much easier to read and interact with: you can
have every thing in the same window.  (no need for a separate editor
and a separate shell)

But, then again, perhaps I am a bit biased  ;-)

Andr? Roberge




The idea is that a student can read the file just like any text file,
but they can simultaneously interact with its code in the Shell.  I
think this is a very useful and simple format.
>
> The goal here is to create something that would be of value to both math and programming students.  A math student wouldn't have to understand the code in order to use it.  However, it's all there if they want to inspect it.  Hopefully an interested reader would end up learning both some math and some programming.
>
> In the beginning I refer to using tuples to represent fractions and Cartesian points.  That is because I had created some earlier lessons where I was trying to keep things minimal.  However, in this lesson it makes a lot of sense to introduce a simple Rational class.  I only implement __init__ and __repr__, making it kind of a fancy struct.  With just that very simple class and a function to generate the mediant of two rationals, you can generate ALL non-negative rationals!  It's really very interesting.
>
> If used in a programming class, we would of course then go back and fill in the Rational class with __add__, __mul__, etc.  But in the context of a typical math class where many of the students aren't sure they even want to learn programming at all, I think this kind of an approach could be useful.  They could use the code as is, and, who knows, they might even be intrigued to try to understand it?
>
> I've noticed that LOTS of students don't really have a good grasp of the rationals at all, and that's not good.  It is only by means of the rational that you can articulate the irrational.  I just recently discovered Farey sequences and Ford circles.  These things have been around now for awhile, but I don't think I've ever seen them discussed in a high school math text!
>
> I appreciate any suggestions, especially along programming lines, that people may have.
>
> Thanks,
>
> - Michel Paul
>
>
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
>
>

From kirby.urner at gmail.com  Fri Aug 24 03:49:47 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 23 Aug 2007 18:49:47 -0700
Subject: [Edu-sig] modeling the rational numbers
In-Reply-To: <3D142BFDEDAC8D46A40F4EA0B36D1F3501888508@MAIL.bhusd.k12.ca.us>
References: <f604188c0708231239n44cb4850if73d640d3a96a239@mail.gmail.com>
	<3D142BFDEDAC8D46A40F4EA0B36D1F3501888508@MAIL.bhusd.k12.ca.us>
Message-ID: <f604188c0708231849k34db1d30h2540759585e42f32@mail.gmail.com>

On 8/23/07, Michel Paul <mpaul at bhusd.k12.ca.us> wrote:

> I appreciate any suggestions, especially along programming lines, that people may have.
>
> Thanks,
>
> - Michel Paul

Make sure you check out The Book of Numbers by Conway and Guy,
and Sloane's On-Line Encyclopedia of Integer Sequences for programming
ideas.

Absolutely right to focus on Rationals as a Python class, to reinforce
student understanding (or to help nurture it in the first place).  Using
__add__ and __mul__ sets the stage for redefining these ops again
and again, over different sets of elements (e.g. polynomials, complex
numbers).

If you write it so that numerators and denominators accept Rationals
as input types, then you have the bases for Continuing Fractions, a
deep and fun topic, especially when the drudgery has been taken out
of it i.e. you have transparent open source algorithms *and* machine
execution.

A paradise, by yesteryear's standards.  An unexplored junkyard by
the standards of today.

Here's a fun generator for phi, though inefficient:

IDLE 1.2.1
>>> def genphi():
	result = 1.0
	while True:
		yield result
		result = (1 + 1/result)

>>> thegen = genphi()
>>> [thegen.next() for term in range(10)]
[1.0, 2.0, 1.5, 1.6666666666666665, 1.6000000000000001, 1.625,
1.6153846153846154, 1.6190476190476191, 1.6176470588235294,
1.6181818181818182]

Kirby

From kirby.urner at gmail.com  Fri Aug 24 03:54:33 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 23 Aug 2007 18:54:33 -0700
Subject: [Edu-sig] modeling the rational numbers
In-Reply-To: <f604188c0708231849k34db1d30h2540759585e42f32@mail.gmail.com>
References: <f604188c0708231239n44cb4850if73d640d3a96a239@mail.gmail.com>
	<3D142BFDEDAC8D46A40F4EA0B36D1F3501888508@MAIL.bhusd.k12.ca.us>
	<f604188c0708231849k34db1d30h2540759585e42f32@mail.gmail.com>
Message-ID: <f604188c0708231854w446012f7i9268ec7cc66eb651@mail.gmail.com>

On 8/23/07, kirby urner <kirby.urner at gmail.com> wrote:

> If you write it so that numerators and denominators accept Rationals
> as input types, then you have the bases for Continuing Fractions,

More typically called Continued Fractions of course:

http://archives.math.utk.edu/articles/atuyl/confrac/

More code right here in this archive (going back to CP4E days),
or check my website e.g.:

http://www.4dsolutions.net/ocn/numeracy0.html
(scroll to bottom -- vintage turn of the millennium Pythonic stuff). [1]

Kirby

[1] Re "when did the millennium turn":
http://members.aol.com/rotanasnem/poster.htm

From jeff at taupro.com  Fri Aug 24 07:07:32 2007
From: jeff at taupro.com (Jeff Rush)
Date: Fri, 24 Aug 2007 00:07:32 -0500
Subject: [Edu-sig] Rich Data Streams
In-Reply-To: <f604188c0708231609t48ea9e27ia56f014f7318dbec@mail.gmail.com>
References: <f604188c0708231239n44cb4850if73d640d3a96a239@mail.gmail.com>	
	<46CE0D8B.3020800@taupro.com>
	<f604188c0708231609t48ea9e27ia56f014f7318dbec@mail.gmail.com>
Message-ID: <46CE6794.5090306@taupro.com>

kirby urner wrote:
> On 8/23/07, Jeff Rush <jeff at taupro.com> wrote:
> 
>> Kirby, I've seen your posts re building up a reusable set of data for teaching
>> before, and I think it is a good idea.  Where are you collecting and making
>> this information available?  It seems like a single project under source
>> control would allow others to utilize and contribute to such a stockpile,
>> piece by piece.
> 
> I'm more just into upholding edu-sig's reputation as a source of
> great ideas.  Rich Data Structures & Streams, you saw it here
> first.

I was afraid of that. ;-(  It would make a valuable resource.

The world has more than enough great ideas -- but a severe shortage of those
who adopt them, refine them and bring them into fruition.  I see this here,
from the community as a whole, on edu-sig and we've seen it for the past five
years on the various advocacy lists.  An issue gets raised, ideas flow in, and
nothing happens.  Sometime later the same is raised again and many of the same
ideas come in.  And truly good ideas languish because those rare, precious
people with a tendency to step forward already have a (over) full slate and
cannot take on any more while the rest consider ideas their sole contribution.
 It is the birthing and raising not the conception that takes more effort -
ask any parent.

I've just been frustrated lately across several spheres of life with how very
hard it is to get people, in general, to get involved, to take on meaningful
projects even those they agree are valuable.  The explanation eludes me and
keeps me awake at night and I ask those I meet from other walks of life why.

----
Be careful.  If you wave your hands around wildly like that for too long,
you're likely to fly up into the air and bump your head against the ceiling.


From lac at openend.se  Fri Aug 24 07:46:43 2007
From: lac at openend.se (Laura Creighton)
Date: Fri, 24 Aug 2007 07:46:43 +0200
Subject: [Edu-sig] Rich Data Streams
In-Reply-To: Message from Jeff Rush <jeff@taupro.com> 
	of "Thu, 23 Aug 2007 17:43:23 CDT." <46CE0D8B.3020800@taupro.com> 
References: <f604188c0708231239n44cb4850if73d640d3a96a239@mail.gmail.com>
	<46CE0D8B.3020800@taupro.com> 
Message-ID: <200708240546.l7O5khYc015611@theraft.openend.se>


I just saw this:
http://www.gapminder.org/

play the TED video.

Then go play with things here:
http://www.gapminder.org/gapminderworld/help/gapminder_world_help.htm

This has been done by the Karolinska Instititet in Stockholm.  The
'Create your own project' part does not appear to be ready yet, but
I think that this would be a lot of fun to use.

Laura 



From delza at livingcode.org  Fri Aug 24 08:06:01 2007
From: delza at livingcode.org (Dethe Elza)
Date: Fri, 24 Aug 2007 09:06:01 +0300
Subject: [Edu-sig] Rich Data Streams
In-Reply-To: <46CE6794.5090306@taupro.com>
References: <f604188c0708231239n44cb4850if73d640d3a96a239@mail.gmail.com>
	<46CE0D8B.3020800@taupro.com>
	<f604188c0708231609t48ea9e27ia56f014f7318dbec@mail.gmail.com>
	<46CE6794.5090306@taupro.com>
Message-ID: <24d517dd0708232306s1a56b896tbb75f30b5ca3597@mail.gmail.com>

On 8/24/07, Jeff Rush <jeff at taupro.com> wrote:
> kirby urner wrote:
> >> Kirby, I've seen your posts re building up a reusable set of data for teaching
> >> before, and I think it is a good idea.  Where are you collecting and making
> >> this information available?  It seems like a single project under source
> >> control would allow others to utilize and contribute to such a stockpile,
> >> piece by piece.
> >
> > I'm more just into upholding edu-sig's reputation as a source of
> > great ideas.  Rich Data Structures & Streams, you saw it here
> > first.
>
> I was afraid of that. ;-(  It would make a valuable resource.

Jeff, if you have an idea where to store pointers to rich data sources
(Python Wiki maybe?), we could start collecting them there.  Here are
a few for starters:

ISO Country Codes list: http://xml.coverpages.org/country3166.html

Moby Word Lists: http://www.dcs.shef.ac.uk/research/ilash/Moby/

MathWorld, lookup formulas to your hearts content: http://mathworld.wolfram.com/

There are many more, of course, and I too would love to see a good
place where we could collect them.

See the Frink language for a interesting approach: Many data sources
are built-ins to Frink, and the language uses units rather than simple
numbers to represent data.
http://futureboy.homeip.net/frinkdocs/

HTH

--Dethe

From lac at openend.se  Fri Aug 24 08:13:54 2007
From: lac at openend.se (Laura Creighton)
Date: Fri, 24 Aug 2007 08:13:54 +0200
Subject: [Edu-sig] Rich Data Streams
In-Reply-To: Message from Jeff Rush <jeff@taupro.com> 
	of "Fri, 24 Aug 2007 00:07:32 CDT." <46CE6794.5090306@taupro.com> 
References: <f604188c0708231239n44cb4850if73d640d3a96a239@mail.gmail.com>
	<46CE0D8B.3020800@taupro.com>
	<f604188c0708231609t48ea9e27ia56f014f7318dbec@mail.gmail.com>
	<46CE6794.5090306@taupro.com> 
Message-ID: <200708240613.l7O6DsSR019975@theraft.openend.se>

In a message of Fri, 24 Aug 2007 00:07:32 CDT, Jeff Rush writes:
>I've just been frustrated lately across several spheres of life with how 
>very
>hard it is to get people, in general, to get involved, to take on meaning
>ful
>projects even those they agree are valuable.  The explanation eludes me a
>nd
>keeps me awake at night and I ask those I meet from other walks of life w
>hy.

One reason is that having ideas is easy.  Work is work.  One thing that
I have found that has had a limited amount of success -- though better
than near 0 success, as was before -- is for you to step in, take the
idea, and break it down into tasks that would need doing before it
is implemented.  This may need collaboration with the idea-haver, but
not always.  Then organise something -- a sprint, say to go make
code out of the idea.  People are justifiably afraid of getting
involved in a project that could suck up all their available
free time and more, and give them a responsibility that they will be
stuck with forever.  If the thing starts out as shared, there can be
some trust that it won't become an intolerable burden later -- and
that ducking out later to do something else that is interesting
won't damage a community that in some way has become dependent on you.

Laura

From tjd at sfu.ca  Fri Aug 24 09:10:38 2007
From: tjd at sfu.ca (Toby Donaldson)
Date: Fri, 24 Aug 2007 00:10:38 -0700
Subject: [Edu-sig] Scratch interface for Python, and network programming
In-Reply-To: <a2f565170708240008k2da4b372qce3c745aecda886@mail.gmail.com>
References: <a2f565170708240008k2da4b372qce3c745aecda886@mail.gmail.com>
Message-ID: <a2f565170708240010q7ad55b17j1eeff077d4dc7ae2@mail.gmail.com>

>> I am also thrilled by the idea of Scratch in Python, but this brings
>> us up against the limitations of the web. The fact that Scratch apps
>> can be shared on the web is a crucial advantage. Could Python Scratch
>> be targeted to Jython to provide sharability?

> To Jython, or if we keep to the limited functionality of Scratch, to
> Flash, which would be more self-contained (and faster) than Java.
> Another advantage to using PyGame is that we could provide export to
> self-contained executables, to run the games on Mac, Windows, or
> Linux.  Scratch itself has not yet been ported to Linux (sad, since it
> is built on top of Squeak, which runs fine on Linux), keeping it off
> of platforms such as XO and my trusty N800.
>
> I like the idea of virtual Roombas, especially as a leaping-off point.
> I can imagine kids costomizing their Roombas: spinning blades, laser
> turrets, even Steampunk Roombas.  Once they have a platform to build
> on, anything is possible.

Robocode has done something similar in Java: http://robocode.sourceforge.net/
I've used Robocode with 1st year university students, and while a few
students really go into, most found it only mildly interesting, like
an old-fashioned video game.

Roomba (Create) simulation software exists at least for player/stage
(http://playerstage.sourceforge.net/) and Microsoft Robotics  Studio
(http://msdn2.microsoft.com/en-us/robotics/default.aspx).

I know Python is popular with Player/stage, and it has 2D graphics (3D
in progress), and the ability to use simulations of real sensors (e.g.
expensive laser sensors). It's more of a research tool, but packaging
it up in an education distribution might be worth considering.

The Microsoft Robotics Studio comes with impressive 3D graphics, and
also physics, e.g. so when to Sumo iCreate's bump into each other,
they lift up off the ground a little. Some of the demos are nice; I
have no idea if it works with Python, though.

By the way, here's an interesting video using 36 Create's:
http://www.youtube.com/watch?v=b_kZmatqAaQ

And speaking of the Create, it's quite a nice, cost-effective robot,
and worth looking at for educational purposes:
http://www.irobot.com/sp.cfm?pageid=305

It would be fun to connect a Create into the Python turtle package to
simulate the old turtle graphics drawing robots.

If you haven't seen the demo video, it's worth a look:
http://www.youtube.com/watch?v=UT2bPx9k7D4

Toby
--
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University (Surrey)

From kirby.urner at gmail.com  Fri Aug 24 17:02:05 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 24 Aug 2007 08:02:05 -0700
Subject: [Edu-sig] Rich Data Streams
In-Reply-To: <46CE6794.5090306@taupro.com>
References: <f604188c0708231239n44cb4850if73d640d3a96a239@mail.gmail.com>
	<46CE0D8B.3020800@taupro.com>
	<f604188c0708231609t48ea9e27ia56f014f7318dbec@mail.gmail.com>
	<46CE6794.5090306@taupro.com>
Message-ID: <f604188c0708240802m1a18e07fu20905fefce880182@mail.gmail.com>

On 8/23/07, Jeff Rush <jeff at taupro.com> wrote:

> > I'm more just into upholding edu-sig's reputation as a source of
> > great ideas.  Rich Data Structures & Streams, you saw it here
> > first.
>
> I was afraid of that. ;-(  It would make a valuable resource.
>

Yes, valuable as in we might use it to our competitive advantage in
order to recruit more students into our program.

> The world has more than enough great ideas -- but a severe shortage of those
> who adopt them, refine them and bring them into fruition.  I see this here,

I did put together cities.xml:
http://www.4dsolutions.net/ocn/python/cities.xml

But just randomly piling large sets of data across all subjects and
making someone king of that hill doesn't necessarily sound like a
good idea to me.

Sounds more like something they'd try in Texas. ;-)

> from the community as a whole, on edu-sig and we've seen it for the past five
> years on the various advocacy lists.  An issue gets raised, ideas flow in, and

Edu-sig has been doing Python Advocacy for longer than any of
the so-called advocacy lists right?  Go edu-sig!

> nothing happens.  Sometime later the same is raised again and many of the same
> ideas come in.  And truly good ideas languish because those rare, precious
> people with a tendency to step forward already have a (over) full slate and
> cannot take on any more while the rest consider ideas their sole contribution.
>  It is the birthing and raising not the conception that takes more effort -
> ask any parent.

I'm working with other busy gnu math teachers on carving out a
niche in the ecosystem, so like stashes of polyhedral OFF files,
X3D stuff, EIG stuff, is our specific rich data.

But do I try to jumble my stuff with that of every other teacher?
No.  We gnu math teachers are actually kinda cliquey.

Any other big American city could do what we do and intercept
Pentiums headed for the landfill.  Free Geek (freegeek.org)
doesn't make a secret of how it works.  But *do* they?

We're maybe just not so lazy in Portland?

> I've just been frustrated lately across several spheres of life with how very
> hard it is to get people, in general, to get involved, to take on meaningful
> projects even those they agree are valuable.  The explanation eludes me and
> keeps me awake at night and I ask those I meet from other walks of life why.

I think sometimes football metaphors help.  Something about different
teams not wanting to share all the same coaches (at least not
simultaneously).

Kirby

From kirby.urner at gmail.com  Sat Aug 25 20:57:26 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Sat, 25 Aug 2007 11:57:26 -0700
Subject: [Edu-sig] Namespaces for Children
Message-ID: <f604188c0708251157l597802b2q69248c512e99b88c@mail.gmail.com>

Here's an excerpt of stuff posted to Wwwanderers (another Yahoo! group
I frequent).

My purpose is sharing it here is to suggest how some classrooms *might*
be introducing the concept of namespaces to children, using chemistry and
Sim Earth style simulations for themes.  More on PHYSOC this month:
http://listserv.uark.edu/archives/physoc.html

==== sample session slash source code ===

>>> from ecology import StateOfMatter
>>> StateOfMatter.Gas
"""
StateOfMatter.Gas:

molecular degrees of freedom maximal
though not excited to plasma state
(vertex-bond universal joint symbol).
"""

>>> StateOfMatter.Liquid
"""
StateOfMatter.Liquid:

more hinge-like and fluid, as if edge
bonded (but not really -- the math is
actually quite complicated!)
"""

etc.

Plus inside SolarSystem.py we find:

class Planet (OrbitingObject) :
    """
    A dynamic of gases, liquids and solids,
    plus radiation and gravity.

    Gibbs Phase Rule pertains.

    Please subclass this Planet for your
    own Planet classes.

    """
    def __init__(self, theplanet = "Earth",
                 time = "2007 AD") # default
        # self.__dict__ local namespace gets
        # populated from SQL database by
        # Gas, Liquid and Solid objects
        pass

    def run(self):
        # gets us going, called from default
        # Solarsystem object
        pass

    def orbit(self):
        # some mechanical model goes here
        # (take your best shot -- Newton's
        # is pretty cool), or accept superclass
        # default
        pass

    def collide(self, other):
        # if thinking to play a game of
        # Velikovskian Pool (not my game,
        # but some like it...)
        pass


def main():
    mysun = Sun()
    myplanet = Planet()
    mysun.add(myplanet)
    mymoon = myplanet.add(Moon())
    mysolarsystem = SolarSystem(mysun, planets = (myplanet,))
    mysolarsystem.run()  # whatever business rules

so...

>>> from solarsystem import main # not case sensitive

>>> solarsystem.main()

Kirby

From da.ajoy at gmail.com  Sat Aug 25 21:32:13 2007
From: da.ajoy at gmail.com (Daniel Ajoy)
Date: Sat, 25 Aug 2007 14:32:13 -0500
Subject: [Edu-sig] Rich Data Streams
Message-ID: <46D03D6D.22836.1333348A@da.ajoy.gmail.com>

For the OLPC I had suggested the following datasets

http://wiki.laptop.org/go/Educational_content_ideas/data_sets


Daniel


From kirby.urner at gmail.com  Sat Aug 25 22:00:25 2007
From: kirby.urner at gmail.com (kirby urner)
Date: Sat, 25 Aug 2007 13:00:25 -0700
Subject: [Edu-sig] Rich Data Streams
In-Reply-To: <46D03D6D.22836.1333348A@da.ajoy.gmail.com>
References: <46D03D6D.22836.1333348A@da.ajoy.gmail.com>
Message-ID: <f604188c0708251300n431fbefdjc478de00f2dc2cfb@mail.gmail.com>

Yeah, excellent raw material with real world applications.

E.g.:
http://wiki.gleducar.org.ar/wiki/Nombres_Propios_de_Personas

When working on a data transformation between MS Access
and Postgres, we had this need to not use real client data,
which was of a sensitive nature.  The need to manufacture
huge numbers of fake individuals, simply to test a database
design with bogus content, during development, is very real.

The value added by a student of Python would be to take
such raw text files and repackage them in a suitable Python
data structure that could just be imported as a part of a module.

I'm not saying this isn't going on as we speak.  Depends on
the classroom and whether the school keeps a server (usually
you have faculty experts supervising different areas, helping
the data stay sane).

Kirby

On 8/25/07, Daniel Ajoy <da.ajoy at gmail.com> wrote:
> For the OLPC I had suggested the following datasets
>
> http://wiki.laptop.org/go/Educational_content_ideas/data_sets
>
>
> Daniel
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>

From da.ajoy at gmail.com  Sun Aug 26 19:26:01 2007
From: da.ajoy at gmail.com (Daniel Ajoy)
Date: Sun, 26 Aug 2007 12:26:01 -0500
Subject: [Edu-sig] Rich Data Streams
In-Reply-To: <mailman.11.1188122404.20564.edu-sig@python.org>
References: <mailman.11.1188122404.20564.edu-sig@python.org>
Message-ID: <46D17159.10598.17E60689@da.ajoy.gmail.com>

On 26 Aug 2007 at 12:00, edu-sig-request at python.org wrote:

> Yeah, excellent raw material with real world applications.
> 
> E.g.:
> http://wiki.gleducar.org.ar/wiki/Nombres_Propios_de_Personas
> 

I used that dataset to decode an anagram. A person in a blog
had said:

I love [anagramedName].

I wanted to know who that person was.

I used Logo, though :)

Another good one could be real normal-distributed data.
Specially if it comes from something that has world wide 
importance.

also, world temperature measurements.

distances between cities

how do you say "I love you" in different languages.

dates of important geological events.

....

Daniel


From heistooheavy at yahoo.com  Sun Aug 26 20:12:17 2007
From: heistooheavy at yahoo.com (Richard Guenther)
Date: Sun, 26 Aug 2007 11:12:17 -0700 (PDT)
Subject: [Edu-sig] Rich Data Streams
Message-ID: <652689.668.qm@web63304.mail.re1.yahoo.com>

More data resources here:

http://www.lttechno.com/links/spreadsheets.html

the best part of the above page is probably the link to:

http://www.k12science.org/collabprojs.html


Richard


----- Original Message ----
From: Daniel Ajoy <da.ajoy at gmail.com>
To: edu-sig at python.org
Sent: Sunday, August 26, 2007 11:26:01 AM
Subject: Re: [Edu-sig] Rich Data Streams

On 26 Aug 2007 at 12:00, edu-sig-request at python.org wrote:

> Yeah, excellent raw material with real world applications.
> 
> E.g.:
> http://wiki.gleducar.org.ar/wiki/Nombres_Propios_de_Personas
> 

I used that dataset to decode an anagram. A person in a blog
had said:

I love [anagramedName].

I wanted to know who that person was.

I used Logo, though :)

Another good one could be real normal-distributed data.
Specially if it comes from something that has world wide 
importance.

also, world temperature measurements.

distances between cities

how do you say "I love you" in different languages.

dates of important geological events.

....

Daniel

_______________________________________________
Edu-sig mailing list
Edu-sig at python.org
http://mail.python.org/mailman/listinfo/edu-sig







       
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search 
that gives answers, not web links. 
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20070826/1bc2ae3c/attachment.htm 

From radenski at studypack.com  Mon Aug 27 00:04:28 2007
From: radenski at studypack.com (Atanas Radenski)
Date: Sun, 26 Aug 2007 15:04:28 -0700
Subject: [Edu-sig] modeling the rational numbers
In-Reply-To: <3D142BFDEDAC8D46A40F4EA0B36D1F3501888508@MAIL.bhusd.k12.ca.us>
References: <f604188c0708231239n44cb4850if73d640d3a96a239@mail.gmail.com>
	<3D142BFDEDAC8D46A40F4EA0B36D1F3501888508@MAIL.bhusd.k12.ca.us>
Message-ID: <20070826150428.w99bdyrcowgsc4gg@webmail.studypack.com>


Quoting Michel Paul <mpaul at bhusd.k12.ca.us>:

> This is simply a Python module that blends text and code.

This is a good illustration that Python is a particularly suitable  
language for literate programming  
(http://en.wikipedia.org/wiki/Literate_programming).

> The goal here is to create something that would be of value to both   
> math and programming students.

Yes, indeed, this kind of texts can be beneficial for both math  
students and programming students.

Returning back to my years as a *programming* student, I think I would  
have been excited about the potential of lazy evaluation  
(http://en.wikipedia.org/wiki/Lazy_evaluation) in Python.

Years ago I implemented an implicit lazy evaluation interpreter for  
John Backus' FP language, but because it was the *only* evaluation  
mode for all sequences, it made the whole interpreter too slow.  
Python's lazy evaluation is explicit and hence employed only as  
needed, and obviously it does not impose unacceptable performance  
penalties.

Returning back to my years as a *math* student, Michel's example would  
have helped me to understand the potential of Python as a tool for  
modeling of interesting math concepts (in contrast to the widespread  
view to programming languages as number-crunching tools).

Great writing, Michel. I hope that you can post more like this.

Atanas

-- 
Atanas Radenski
mailto:radenski at studypack.com   http://studypack.com
mailto:radenski at chapman.edu     http://www1.chapman.edu/~radenski



From clare at girlstart.org  Mon Aug 27 16:08:45 2007
From: clare at girlstart.org (Clare Richardson)
Date: Mon, 27 Aug 2007 09:08:45 -0500
Subject: [Edu-sig] Scratch interface for Python,
	and network programming games.
In-Reply-To: <882FE2ED-03A5-4790-A3C6-DE93DFFB1B14@stratolab.com>
References: <637347.49349.qm@web63309.mail.re1.yahoo.com><24d517dd0708220244i2b8d50f4o36b67cc9a2298b12@mail.gmail.com>
	<882FE2ED-03A5-4790-A3C6-DE93DFFB1B14@stratolab.com>
Message-ID: <2768575AE4BD2740AFC4798322F0C1B0C21545@pandora.girlstart.org>

There's an intro CS course at UT Austin that has an assignment where
students create "critters" that can eat each other, etc, and the
students in the class have a big tournament to see whose critter is the
last man standing.  This is often the favorite assignment of the
semester, and many students from past years even come back for the
tournament!

The assignment comes in two parts:
1) Write an interpreter for the "Critter language"
2) Define your own Critter in the Critter language

The class assignment is in Java, but could easily be turned into Python.

The project description and code are on this page:
http://www.cs.utexas.edu/users/jdiamond/cs315h/index.html#Proj3

Clare Richardson
Technology and Program Coordinator
Girlstart
www.girlstart.org

-----Original Message-----
From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On
Behalf Of Winston Wolff
Sent: Wednesday, August 22, 2007 4:35 PM
To: Dethe Elza
Cc: edu-sig at python.org
Subject: [Edu-sig] Scratch interface for Python,and network programming
games.

Hi Dethe-

I have been thinking of exactly the same thing--a Scratch type  
environment for Python.  And I've also purchased a Nintendo DS  
development kit, hoping to make a Python to Nintendo DS development  
system.  Haven't had time to work on it though with my summer  
classes.  I should have more time in the fall, perhaps we can  
collaborate?

My biggest interest on the Scratch/Python angle right now is to  
develop some team programming games.  I.e. you write a program using  
Python raw or Python via a Scratch interface for beginners, and then  
you throw your program into the ring via the network and have it  
compete against other students.



Winston Wolff
winstonw at stratolab.com
(646) 827-2242

------------------------------------------------------------------------

--
Stratolab - video game courses for kids in new york - http:// 
stratolab.com

From john.zelle at wartburg.edu  Mon Aug 27 18:15:03 2007
From: john.zelle at wartburg.edu (John Zelle)
Date: Mon, 27 Aug 2007 11:15:03 -0500
Subject: [Edu-sig] Scratch interface for Python,
	and network programming games.
In-Reply-To: <2768575AE4BD2740AFC4798322F0C1B0C21545@pandora.girlstart.org>
References: <637347.49349.qm@web63309.mail.re1.yahoo.com>
	<882FE2ED-03A5-4790-A3C6-DE93DFFB1B14@stratolab.com>
	<2768575AE4BD2740AFC4798322F0C1B0C21545@pandora.girlstart.org>
Message-ID: <200708271115.03590.john.zelle@wartburg.edu>

This is a very interesting assignment, but I would just point out that this is 
hardly an "intro CS course." They are doing these particular projects in an 
intermediate/advanced data structures/algorithms class. That would be a 3rd 
semester college-level course for those who entered without a programming 
background. At least that is where the link goes, and that seems appropriate 
for the assignment. 

Just building this as a Python API, rather than a separate interpreter might 
make for an interesting (and somewhat simpler project). The "critters" could 
then easily be programmed right in Python, which is something that even 
beginning programmers could do.

--John


On Monday 27 August 2007 9:08 am, Clare Richardson wrote:
> There's an intro CS course at UT Austin that has an assignment where
> students create "critters" that can eat each other, etc, and the
> students in the class have a big tournament to see whose critter is the
> last man standing.  This is often the favorite assignment of the
> semester, and many students from past years even come back for the
> tournament!
>
> The assignment comes in two parts:
> 1) Write an interpreter for the "Critter language"
> 2) Define your own Critter in the Critter language
>
> The class assignment is in Java, but could easily be turned into Python.
>
> The project description and code are on this page:
> http://www.cs.utexas.edu/users/jdiamond/cs315h/index.html#Proj3
>
> Clare Richardson
> Technology and Program Coordinator
> Girlstart
> www.girlstart.org
>
> -----Original Message-----
> From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On
> Behalf Of Winston Wolff
> Sent: Wednesday, August 22, 2007 4:35 PM
> To: Dethe Elza
> Cc: edu-sig at python.org
> Subject: [Edu-sig] Scratch interface for Python,and network programming
> games.
>
> Hi Dethe-
>
> I have been thinking of exactly the same thing--a Scratch type
> environment for Python.  And I've also purchased a Nintendo DS
> development kit, hoping to make a Python to Nintendo DS development
> system.  Haven't had time to work on it though with my summer
> classes.  I should have more time in the fall, perhaps we can
> collaborate?
>
> My biggest interest on the Scratch/Python angle right now is to
> develop some team programming games.  I.e. you write a program using
> Python raw or Python via a Scratch interface for beginners, and then
> you throw your program into the ring via the network and have it
> compete against other students.
>
>
>
> Winston Wolff
> winstonw at stratolab.com
> (646) 827-2242
>
> ------------------------------------------------------------------------
>
> --
> Stratolab - video game courses for kids in new york - http://
> stratolab.com
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig

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