From kirby.urner at gmail.com  Sun Oct  1 01:00:17 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Sat, 30 Sep 2006 16:00:17 -0700
Subject: [Edu-sig] Calculus with Stickworks (more Gnu Math)
In-Reply-To: <451EE5AD.6090704@optonline.com>
References: <f604188c0609291722j45a24563je3ec826ca610458d@mail.gmail.com>
	<f604188c0609292125ge685741hfdf17a81e3fef32f@mail.gmail.com>
	<451E69DF.4050709@optonline.com>
	<f604188c0609300836u489fd7b7ke1c06f2a7d2a5af8@mail.gmail.com>
	<451EE5AD.6090704@optonline.com>
Message-ID: <f604188c0609301600j236584a3re3c5887780179bdd@mail.gmail.com>

On 9/30/06, Arthur <ajsiegel at optonline.net> wrote:
> kirby urner wrote:
>
> >> You are taking something open and public, and  narrowing it, and
> >> appropriating it.
> >
> > Absolutely.  My right and freedom.  No apologies.  Go for it.
>
> You are free to do it, but not by right. Is it your right to do anything
> that no one can stop you from doing? Maybe in a schoolyard sense, yes.
> But not in a grown-up sense.  At least in the world according to me.

Just going by what's in the Python license.  You should be glad I'm as
open and public with my special case narrowing as I am.  Nothing to
keep me from running silent, and just sharing it with my perfect
friends.  I say "should be glad" because yes, I do think my curriculum
writing is high caliber, or I wouldn't be spreading all over
cyberspace (I hope in the right file cabinets -- the vista keeps
shifting).

>
> > In other words:  elegant isn't always my style.
>
> Believe it or not, I think we are more on the same side, than not.  But
> I am forced to remain adversarial, mostly on the issue of style.  Style
> is malleable, so it becomes a choice, a strategy.  Your style - i.e.
> your strategy -  is the basis upon which I am forced to question your
> seriousness.

That's your privilege.  If it were one road in a lonely town, and one
lone red light, you being the light, me racing my engines, then I'd
say we were adversaries.  But it's a four lane freeway each way, no
lights, except what's blinking on my dashboard (the Arthur light keeps
flashing a lot, pesky :-D).

> My style is certainly also open to question.  I like to think that my
> willingness to be abrasive is, at least, a sign of my seriousness.  And
> I am serious. Enough to not feel I need to apologize to anyone for
> engaging you, which others might see as taking something that is none of
> my business, and making it my business. I am exercising my citizenship,
> and am only surpised that others don't feel inclined to do the same.
>
> Art
>

Lots of people engage me, if not here on edu-sig that much.  You and I
go back to Synergetics-L.  People engaged me there.  I fight with Rybo
24/7 on Synergeo.

Rest assured, I get tested a lot, and I don't boast always passing.  I
boast talents, yes, but my powers are strictly limited (yours too
no?).

I goof up, lose at ping pong, bomb in chess (means I lose).

I remember this time I was on Don's boat (where I just was today),
yakking up the amazing superiority of human intelligence over anything
mechanized (giving the birdie to AI), while meanwhile fooling around
with my cell (the one before this Motorola -- it's all my blog).

Just then, it beat me in chess.

I can't tell you how humble I felt losing chess to my stupid cell
phone.  I had to think about the invisible army of engineers behind
that performance, all the chess playing acumen that must have gone
into this program.

That assuaged my ego somewhat (hey, they had an army).  Still... pesky device.

Kirby

From kirby.urner at gmail.com  Mon Oct  2 04:56:44 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Sun, 1 Oct 2006 19:56:44 -0700
Subject: [Edu-sig] Talking about "Handles"
Message-ID: <f604188c0610011956y5bb7c48au32ba8b593afb4839@mail.gmail.com>

A thought about pedagogy:

We say "reference" a lot when talking about a variable's relationship
to a piece of memory.  I'm thinking "handle" could be used more
(optionally -- this is not an instruction) and we could even show a
coffee cup (doesn't have to be coffee -- a mug) with two handles, when
explaing how two (or more) variables may have the same "contents" (a
feature, but also a source of bugs, confusions for beginners).

Python doesn't mind if you use multiple handles for something.
Garbage collection won't happen to anything with a handle in an active
namespace.  More could be said (not necessarily by me).

Kirby

Setting:  Hanging out with Don the boat captain tonight.  His wife is
Jewish and wants to celebrate YK with no distractions, so he's hanging
in the 'hood, planning to sleep on Meliptus (his boat).

From jjposner at snet.net  Mon Oct  2 18:14:38 2006
From: jjposner at snet.net (John Posner)
Date: Mon, 2 Oct 2006 12:14:38 -0400
Subject: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
In-Reply-To: <mailman.7.1159783202.5832.edu-sig@python.org>
Message-ID: <20061002161448.4A87B1E400B@bag.python.org>

Kirby said:

> We say "reference" a lot when talking about a variable's relationship
> to a piece of memory.  I'm thinking "handle" could be used more
> (optionally -- this is not an instruction) and we could even show a
> coffee cup (doesn't have to be coffee -- a mug) with two handles, when
> explaing how two (or more) variables may have the same "contents" (a
> feature, but also a source of bugs, confusions for beginners).

Picking a good metaphor, tailored to the pedagogical situation, is very
important: it provides the critical cognitive bridge from what the student
*already* knows to what you want the student to *learn*.

The best metaphor I've encountered for the concept of variable, as
implemented by Python, is John Zelle's. On page 34 of "Python Programming:
An Introduction to Computer Science", he says:

  Assigning a variable is like putting one of those little yellow
  sticky notes on the value and saying, "this is x."

Thinking "sticky note" makes it easy to teach students that:

* Even if "x" is already assigned to one value, you can assign it to another
value. (Take the note off the first value, and stick it onto the second
one.)

* In Python, any variable can be assigned to any value. (By contrast, some
languages have "colored sticky notes", and you can't stick a BLUE sticky
note on a RED value).  John Z, do you take this angle in your book? I didn't
see it, but I confess I may have failed to look thoroughly enough for it!

* You can assign "x" and "y" (etc.) to the same value. (You can place any
number of sticky notes on the same value. A note is always attached to a
value -- a note is never attached to another note.)

* Jut what does the "del" statement actually do? (It removes one sticky note
from a value. If a value loses all its sticky notes, it becomes totally
*incommunicado* -- there's no way to get to the value.)

* What's a namespace? (A bunch of sticky notes.)

* etc., etc.

The coffee-cup-handle metaphor is certainly useful, but IMHO not quite as
spot-on as the sticky-note metaphor.

-John Posner



From kirby.urner at gmail.com  Mon Oct  2 19:00:16 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 2 Oct 2006 10:00:16 -0700
Subject: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
In-Reply-To: <20061002161448.4A87B1E400B@bag.python.org>
References: <mailman.7.1159783202.5832.edu-sig@python.org>
	<20061002161448.4A87B1E400B@bag.python.org>
Message-ID: <f604188c0610021000x2b601c69r52c82b88e6aa27bc@mail.gmail.com>

> The coffee-cup-handle metaphor is certainly useful, but IMHO not quite as
> spot-on as the sticky-note metaphor.
>
> -John Posner
>

Excellent review John thanks.

Below is the kind of thing a teacher could project.

IDLE 1.2b2

>>> handle1 = ['coffee','sugar','cream']
>>> handle2 = handle1

>>> id(handle1)
13645944

>>> id(handle2)
13645944

>>> handle1.sort()  # alphabetize in place

>>> handle2
['coffee', 'cream', 'sugar']

>>> handle3 = handle1
>>> handle3 is handle2
True

So by this time with have a list in Memory with three handles
(handle1, handle2, handle3).

The idea of a cartoon mug with more than one handle seems "sticky" in
the sense that students are unlikely to forget it easily.

BTW, I just searched and found a real two-handled mug for sale in Ireland:
http://www.assistireland.ie/index.asp?locID=1885&docID=1742

One reason I like this "handle" nomenclature is kids use "handles" for
themselves, i.e. for chat rooms, other places where some notion of
primitive identity is required (Second Life is especially popular
these days).  So there's already this builtin sense of "me" (myself)
with multiple handles, multiple ways for others to get in touch with
the same identity.

I like the idea of making Memory a spatial affair i.e. instead of just
using flat rectangles or circles to represent contents, we could use
3D-looking balloons or balls.

Balloons with multiple strings is a good analogy (or just the one
string).  When no strings attach, the balloon simply floats off, out
of sight out of mind (out of Memory).

Cartoon animations of Garbage Collection:  what should those look like?

We need to connect here: a discussion of immutability.

A list can be shaken and stirred without losing its identity.

However, strings are considered immutables in Python, meaning if you
fix a typo, you get back a new string, not a change in the original
Memory container.

Tuples are similar, in that you can't change the handles inside a
tuple -- but you *can* change the Memory contents of what the handles
point to, e.g.:

>>> mytuple = (handle1, handle2, handle3)
>>> mytuple[1]
['coffee', 'cream', 'sugar']
>>> handle3[2] = 'vanilla flavoring'
>>> mytuple[1]
['coffee', 'cream', 'vanilla flavoring']

What's a good metaphor for explaining about intern?

>>> help(intern)
Help on built-in function intern in module __builtin__:

intern(...)
    intern(string) -> string

    ``Intern'' the given string.  This enters the string in the (global)
    table of interned strings whose purpose is to speed up dictionary lookups.
    Return the string itself or the previously interned string object with the
    same value.

>>>

Kirby

From francois.schnell at gmail.com  Mon Oct  2 22:27:29 2006
From: francois.schnell at gmail.com (francois schnell)
Date: Mon, 2 Oct 2006 22:27:29 +0200
Subject: [Edu-sig] Fwd: [EuroPython] Children first and a hole-in-the-wall
In-Reply-To: <7be3f35d0610021215x159f8eecja0b7d717c0cbd0fd@mail.gmail.com>
References: <7be3f35d0610021215x159f8eecja0b7d717c0cbd0fd@mail.gmail.com>
Message-ID: <13a83ca10610021327x124d877do3c1d8bc4184a73a7@mail.gmail.com>

Just saw this on the europython list :

---------- Forwarded message ----------
From: Harald Armin Massa <haraldarminmassa at gmail.com>
Date: 02-Oct-2006 21:15
Subject: [EuroPython] Children first and a hole-in-the-wall
To: "europython at python.org" <europython at python.org>

Hello,

all who were fascinated by the "children first" talk of Alan Key might find
this article interesting to:

http://www.greenstar.org/butterflies/Hole-in-the-Wall.htm

So please try to imagine the possibilities given by OLPC with Python
preinstalled

Harald


-- 
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Reinsburgstra?e 202b
70197 Stuttgart
0173/9409607
-
Python: the only language with more web frameworks than keywords.
_______________________________________________
EuroPython mailing list
EuroPython at python.org
http://mail.python.org/mailman/listinfo/europython
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20061002/f7948082/attachment.htm 

From ajsiegel at optonline.net  Mon Oct  2 23:12:52 2006
From: ajsiegel at optonline.net (Arthur Siegel)
Date: Mon, 02 Oct 2006 17:12:52 -0400
Subject: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
In-Reply-To: <f604188c0610021000x2b601c69r52c82b88e6aa27bc@mail.gmail.com>
References: <mailman.7.1159783202.5832.edu-sig@python.org>
	<20061002161448.4A87B1E400B@bag.python.org>
	<f604188c0610021000x2b601c69r52c82b88e6aa27bc@mail.gmail.com>
Message-ID: <1159823572.29157.12.camel@localhost>

On Mon, 2006-10-02 at 10:00 -0700, kirby urner wrote:

> >>> handle1 = ['coffee','sugar','cream']
> >>> handle2 = handle1
> 
> >>> id(handle1)
> 13645944
> 
> >>> id(handle2)
> 13645944

I always thought that when presenting this it is natural and important -
in order for the student to truly get it - to do an "as opposed to"
thingy.

>handle3=list(handle1)
>handle1[0]='tea'
>handle1
>['tea','sugar','cream']
>handle3
>['coffee','sugar','cream']

To me this is so essential that I have argued that the fact that neither
the list type having a copy method or the copy function being a built-in
is a wart. But I think if it is a wart it impacts discovering 
Python, i.e. self-teaching, rather than teaching Python and learning
Python more formally.

Anyway, I would advocate the "as opposed to" be integrated into such a
presentation.

Art


From Scott.Daniels at Acm.Org  Tue Oct  3 00:08:41 2006
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Mon, 02 Oct 2006 15:08:41 -0700
Subject: [Edu-sig] Talking about "Handles"
In-Reply-To: <f604188c0610011956y5bb7c48au32ba8b593afb4839@mail.gmail.com>
References: <f604188c0610011956y5bb7c48au32ba8b593afb4839@mail.gmail.com>
Message-ID: <efs2jc$2n9$1@sea.gmane.org>

kirby urner wrote:
> We say "reference" a lot when talking about a variable's relationship
> to a piece of memory.  I'm thinking "handle" could be used more
> (optionally -- this is not an instruction) and we could even show a
> coffee cup (doesn't have to be coffee -- a mug) with two handles, when
> explaing how two (or more) variables may have the same "contents" (a
> feature, but also a source of bugs, confusions for beginners).

This metaphor may be good for references, but not for Python.  You are
left with the intuition that you can look at the mug and enumerate the
handles.  Maybe a an object is a living thing with lasers shining on it
(referring to it), that may shrivel up and die if it gets no light.

-- Scott David Daniels
Scott.Daniels at Acm.Org


From Scott.Daniels at Acm.Org  Tue Oct  3 00:22:21 2006
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Mon, 02 Oct 2006 15:22:21 -0700
Subject: [Edu-sig] Talking about "Handles"
In-Reply-To: <f604188c0610011956y5bb7c48au32ba8b593afb4839@mail.gmail.com>
References: <f604188c0610011956y5bb7c48au32ba8b593afb4839@mail.gmail.com>
Message-ID: <efs3d0$53r$1@sea.gmane.org>

I'm catching up here, and just read the namespaces thing --
How about "namespaces are like card catalogs in a closed stack library."
At the Library of Congress (here in the U.S.), up through when I last
went (some time ago), any U.S. citizen can go in and find a book in a
catalog (I'm certain electronically automated by now) -- they are kind
of sprinkled around as I remember), fill out a slip of paper, including
a desk number, and wait at that desk.  If no member of congress has the
book out, it shows up on that desk, often in less than 20 minutes.

If a book wound up in the library with no entries in any catalog, it
would effectively be gone, whether or not the buildings vast archives
held the book.  The books don't care, however, how many different
cards reference them (nor even if the only reference to them is
written in some book which _is_ referenced by some card in the catalog).

-- Scott David Daniels
Scott.Daniels at Acm.Org


From kirby.urner at gmail.com  Tue Oct  3 00:47:10 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 2 Oct 2006 15:47:10 -0700
Subject: [Edu-sig] Talking about "Handles"
In-Reply-To: <efs2jc$2n9$1@sea.gmane.org>
References: <f604188c0610011956y5bb7c48au32ba8b593afb4839@mail.gmail.com>
	<efs2jc$2n9$1@sea.gmane.org>
Message-ID: <f604188c0610021547u147204adya89a7018f2d10692@mail.gmail.com>

> This metaphor may be good for references, but not for Python.  You are
> left with the intuition that you can look at the mug and enumerate the
> handles.  Maybe a an object is a living thing with lasers shining on it
> (referring to it), that may shrivel up and die if it gets no light.
>
> -- Scott David Daniels

Good caveat.

I could keep the "mug with many handles" metaphor, but then explain
only the Garbage Collector really knows when it's time for a mug to
meet its maker (i.e. return its piece of Memory to that great Heap in
the Sky).

Kirby

From andre.roberge at gmail.com  Tue Oct  3 00:52:40 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Mon, 2 Oct 2006 19:52:40 -0300
Subject: [Edu-sig] Talking about "Handles"
In-Reply-To: <efs3d0$53r$1@sea.gmane.org>
References: <f604188c0610011956y5bb7c48au32ba8b593afb4839@mail.gmail.com>
	<efs3d0$53r$1@sea.gmane.org>
Message-ID: <7528bcdd0610021552r151d184dhe8bbde01eb18caee@mail.gmail.com>

(Fully aware of the potential problems of quoting out of context and
of the limitation of using analogies...)

On 10/2/06, Scott David Daniels <Scott.Daniels at acm.org> wrote:
> I'm catching up here, and just read the namespaces thing --
> How about "namespaces are like card catalogs in a closed stack library."

Analogies to library card catalogs would need to be explained to
today's kids (including those 1st year university students).  If any
analogy is going to be used, I think it should be a future looking one
- or, at least a "time-neutral" one.

I'd prefer something like
namespace <--> book
variable/function/object name <--> character's name in a book
two or more name for same object <--> character's name and alias(es)
or nickname(s)

That being said....  I believe that, just like for learning another
"human" language, nothing beats the "immersion paradigm" to learn any
language, including programming ones.  Just introduce the vocabulary,
use it in context with plenty of different examples and, soon enough,
the students will construct their own "mental map" without referring
to a translation in a different language.

Andr? Roberge

From kirby.urner at gmail.com  Tue Oct  3 01:04:12 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 2 Oct 2006 16:04:12 -0700
Subject: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
In-Reply-To: <1159823572.29157.12.camel@localhost>
References: <mailman.7.1159783202.5832.edu-sig@python.org>
	<20061002161448.4A87B1E400B@bag.python.org>
	<f604188c0610021000x2b601c69r52c82b88e6aa27bc@mail.gmail.com>
	<1159823572.29157.12.camel@localhost>
Message-ID: <f604188c0610021604r71d20a8dk4eb0cdc01c504978@mail.gmail.com>

> Anyway, I would advocate the "as opposed to" be integrated into such a
> presentation.
>
> Art
>

Yes, once bitten in the butt by the fact of a two handled mug, then
comes the question:  "so how do I make sure each handle gets a mug to
itself?"  (as in "why should we share the same beer?").

At this point, we have a couple of trix, one of which you mentioned
(use list(input) to return another list).

Or we might import the copy module.

Or we might "take the whole thing as a slice" i.e. newlist = oldlist[:].

However, the list and slice functions aren't generic enough to work
for generic objects.

I think the key here is to refer to "=" (the equal sign) as an
operator, i.e. a "doer" (we're not asserting the identity of two
objects (as in pre-computer algebra) but assigning a handle to a piece
of memory, giving it a name.

I'm thinking astronomy might come in useful here.  Two namespaces
(mythologies) might connect the stars into completely different
creatures, surrounded by their own respective stories.  You can get
away with this, even if we don't admit to parallel universes thereby
(same stars, different tellings).

Actually *duplicating* a piece of memory (wasteful?), to make the same
contents reside elsewhere (why?), with its own handles, is considered
a semi-esoteric move in Python, not something you'd necessarily need
right out of the box.

There's a builtin bias against it (duplication), because Memory should
be retreated with respect as a finite resource, not squandered
unnecessarily.

But if you *really* need to clone a piece of memory (vs. simply assign
it a new handle), then by all means, import the copy module and even a
deepcopy if you need to.

You have that freedom.  But it's a step away from an everyday operation.

As far as beginners are concerned, they may come to Python with the
expectation that duplicating objects willy nilly is the mark of a good
program ("memory is cheap" we're always saying these days).

Setting them up for a surprise may actually be good pedagogy.

Maybe some teacher text (not necessarily printed) wants to do a "Snake
Bite" icon, with the spin that here's a potential pitfall, but also a
useful lesson, should you fall into it (we learn from these snake
bites and move on).

Kirby

From bert at freudenbergs.de  Tue Oct  3 01:16:01 2006
From: bert at freudenbergs.de (Bert Freudenberg)
Date: Tue, 3 Oct 2006 01:16:01 +0200
Subject: [Edu-sig] Talking about "Handles"
In-Reply-To: <f604188c0610021547u147204adya89a7018f2d10692@mail.gmail.com>
References: <f604188c0610011956y5bb7c48au32ba8b593afb4839@mail.gmail.com>
	<efs2jc$2n9$1@sea.gmane.org>
	<f604188c0610021547u147204adya89a7018f2d10692@mail.gmail.com>
Message-ID: <19061695-B5D0-49EE-BA9C-ABCA1969D722@freudenbergs.de>


Am 03.10.2006 um 00:47 schrieb kirby urner:

>> This metaphor may be good for references, but not for Python.  You  
>> are
>> left with the intuition that you can look at the mug and enumerate  
>> the
>> handles.  Maybe a an object is a living thing with lasers shining  
>> on it
>> (referring to it), that may shrivel up and die if it gets no light.
>>
>> -- Scott David Daniels
>
> Good caveat.
>
> I could keep the "mug with many handles" metaphor, but then explain
> only the Garbage Collector really knows when it's time for a mug to
> meet its maker (i.e. return its piece of Memory to that great Heap in
> the Sky).

A mug to me sounds way too similar to "bit bucket". That's how low- 
level languages (like C++) present variables. Also, it's hard to  
imagine how to describe, say, a linked list as a chain of mugs.

I like to explain objects as balloons, with labeled hooks on its  
surface as variables. A balloon can have more than one leash, but  
each hook holds exactly one leash (still looking for a metaphor that  
naturally has this constraint). Garbage collection then simply occurs  
when all leashes of an object are removed from the hooks - a whole  
tangle of objects might float up. The idea extends even to weak  
references, which is a leash not tied but loosely attached to a hook :)

- Bert -


From ajsiegel at optonline.net  Tue Oct  3 02:02:17 2006
From: ajsiegel at optonline.net (Arthur Siegel)
Date: Mon, 02 Oct 2006 20:02:17 -0400
Subject: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
In-Reply-To: <f604188c0610021604r71d20a8dk4eb0cdc01c504978@mail.gmail.com>
References: <mailman.7.1159783202.5832.edu-sig@python.org>
	<20061002161448.4A87B1E400B@bag.python.org>
	<f604188c0610021000x2b601c69r52c82b88e6aa27bc@mail.gmail.com>
	<1159823572.29157.12.camel@localhost>
	<f604188c0610021604r71d20a8dk4eb0cdc01c504978@mail.gmail.com>
Message-ID: <1159833737.806.15.camel@localhost>

On Mon, 2006-10-02 at 16:04 -0700, kirby urner wrote:
> > Anyway, I would advocate the "as opposed to" be integrated into such a
> > presentation.
> >
> > Art
> >
> Actually *duplicating* a piece of memory (wasteful?), to make the same
> contents reside elsewhere (why?), with its own handles, is considered
> a semi-esoteric move in Python, not something you'd necessarily need
> right out of the box.

In my mind, it is not a matter of needing copy right out of the box.
And that is the argument I keep running into when making this general
case - that teaching "copy" - in any form -  early overemphasizes
something that is "semi-esoteric". And I understand that point.

Except that mutable/non-mutable is cognitively more than semi-esoteric
for the uninitiated.  While there certainly is nothing in the least
esoteric about the list data-type or the assignment operator. 

The argument I keep making and for which I cannot seem to find any
takers, is that essential to explaining/understanding assignment of a
list to a name, is understanding in the negative - i.e., what it is not.
We are still just teaching basic assignment with regard to a list, and I
maintain that doing so effectively should in part be done in the
negative. What it is not silhouetting better what it is.

Art  


From kirby.urner at gmail.com  Tue Oct  3 03:12:19 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 2 Oct 2006 18:12:19 -0700
Subject: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
In-Reply-To: <1159833737.806.15.camel@localhost>
References: <mailman.7.1159783202.5832.edu-sig@python.org>
	<20061002161448.4A87B1E400B@bag.python.org>
	<f604188c0610021000x2b601c69r52c82b88e6aa27bc@mail.gmail.com>
	<1159823572.29157.12.camel@localhost>
	<f604188c0610021604r71d20a8dk4eb0cdc01c504978@mail.gmail.com>
	<1159833737.806.15.camel@localhost>
Message-ID: <f604188c0610021812j47c7a1fey72cb9c43f7553916@mail.gmail.com>

On 10/2/06, Arthur Siegel <ajsiegel at optonline.net> wrote:

> The argument I keep making and for which I cannot seem to find any
> takers, is that essential to explaining/understanding assignment of a
> list to a name, is understanding in the negative - i.e., what it is not.
> We are still just teaching basic assignment with regard to a list, and I
> maintain that doing so effectively should in part be done in the
> negative. What it is not silhouetting better what it is.
>
> Art
>

I'm pretty sure I follow.

I might spin this away from "lists" per se, as the multiple references
to one object in memory picture is not narrowly about just lists, but
any objects, as you well know.

A generic way to initialize an object:

>>> o = object()

The mutability vs. immutability thing is inextricably woven in to the
assignment thread, because of what we're able to do with tuples:
mutate objects in memory without disturbing their tupuloids i.e.
change the contents of a list *in* a tuple.

>>> thelist = ['a']
>>> thetuple = (thelist,)
>>> thetuple[0][0] = 'b'  # not mutating thetuple, but memory object within
>>> thetuple
(['b'],)

When I say something is "semi-esoteric" I'm not arguing that it's
discussion be postponed for very long.

More it's a rationale for the *design* of Python, i.e. why "copy"
requires an import and isn't a builtin.  Esoteric books are on a
higher shelf -- but that doesn't mean you can't grab them down even on
the very first day, if your students are ready to move quickly.

Scott mentioned our not being able to see how many handles a mug has,
but with the sys module we can:

IDLE 1.2b2
>>> import sys
>>> a = ['mug of beer']
>>> b = a
>>> c = a
>>> sys.getrefcount(a)
4
>>> del c
>>> sys.getrefcount(a)
3
>>> help(sys.getrefcount)
Help on built-in function getrefcount in module sys:

getrefcount(...)
    getrefcount(object) -> integer

    Return the reference count of object.  The count returned is generally
    one higher than you might expect, because it includes the (temporary)
    reference as an argument to getrefcount().

"As a former philosophy major, it disturbs me to think that things
disappear when no one is looking at them, but that's exactly what
happens in Python. In general, you can simply forget about memory
management and let Python clean up after you." -- Mark Pilgrim

Kirby

From ajsiegel at optonline.net  Tue Oct  3 04:19:51 2006
From: ajsiegel at optonline.net (Arthur Siegel)
Date: Mon, 02 Oct 2006 22:19:51 -0400
Subject: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
In-Reply-To: <f604188c0610021604r71d20a8dk4eb0cdc01c504978@mail.gmail.com>
References: <mailman.7.1159783202.5832.edu-sig@python.org>
	<20061002161448.4A87B1E400B@bag.python.org>
	<f604188c0610021000x2b601c69r52c82b88e6aa27bc@mail.gmail.com>
	<1159823572.29157.12.camel@localhost>
	<f604188c0610021604r71d20a8dk4eb0cdc01c504978@mail.gmail.com>
Message-ID: <1159841991.19883.12.camel@localhost>

On Mon, 2006-10-02 at 16:04 -0700, kirby urner wrote:
> Or we might import the copy module.
> 
> Or we might "take the whole thing as a slice" i.e. newlist = oldlist[:].
> 

I used the list(handle1) alternative purposefully, based on Alex
Martelli's position on the matter.

The first time I heard him state a position on it was in an exchange on
python-list in which I participated precisely on the subject under
discussion re:referencing and copying   

It was one of the more satisfying discussions I have had on python-list.
Apparently what I was saying was in line with some other discussion he
has having with Anna re: CookBook2, and it seemed to have some influence
in how he intended to approach the issue on "copy" in that edition.
Don't know the end result, as I have CookBook1 and haven't sprung for 2.

 
Here is a reference to that thread

 
http://mail.python.org/pipermail/python-list/2004-August/237278.html

Guido knows that this is a favorite topic of mine and has considered me
quite the nudge for returning to it as often as I do.


Art



From kirby.urner at gmail.com  Tue Oct  3 06:04:31 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 2 Oct 2006 21:04:31 -0700
Subject: [Edu-sig] Fwd: [EuroPython] Children first and a
	hole-in-the-wall
In-Reply-To: <13a83ca10610021327x124d877do3c1d8bc4184a73a7@mail.gmail.com>
References: <7be3f35d0610021215x159f8eecja0b7d717c0cbd0fd@mail.gmail.com>
	<13a83ca10610021327x124d877do3c1d8bc4184a73a7@mail.gmail.com>
Message-ID: <f604188c0610022104nbf10051ycf9f302b020da9e@mail.gmail.com>

interesting to:
>
> http://www.greenstar.org/butterflies/Hole-in-the-Wall.htm
>

An experiment worth doing once I suppose.  Proves kids have natural
ability that we mostly waste and squander.

They deserve real opportunities though, not holes in the wall.  Just
like a Physicist to coldly treat them like guinea pigs.  Continuing
this experiment is a waste of time, and cruel.

There are plenty of adults who could provide real guidance, lots of
technological capability.

We have no excuse to be doing "experiments" on these children.  They
should be given real opportunities.

Kirby

From kirby.urner at gmail.com  Tue Oct  3 06:08:39 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 2 Oct 2006 21:08:39 -0700
Subject: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
In-Reply-To: <1159841991.19883.12.camel@localhost>
References: <mailman.7.1159783202.5832.edu-sig@python.org>
	<20061002161448.4A87B1E400B@bag.python.org>
	<f604188c0610021000x2b601c69r52c82b88e6aa27bc@mail.gmail.com>
	<1159823572.29157.12.camel@localhost>
	<f604188c0610021604r71d20a8dk4eb0cdc01c504978@mail.gmail.com>
	<1159841991.19883.12.camel@localhost>
Message-ID: <f604188c0610022108k6d72b601k3d4b305e33a95d37@mail.gmail.com>

> Here is a reference to that thread
>
>
> http://mail.python.org/pipermail/python-list/2004-August/237278.html
>
> Guido knows that this is a favorite topic of mine and has considered me
> quite the nudge for returning to it as often as I do.
>
>
> Art

<< filing URL for possible follow-up someday >>

Sounds like you've got something nailed.  I'll leave ya to it then.

Edu-sig has nothing to do with all of us agreeing to teach the same way.

I hope I've been plenty clear that I'm interested in *competing* with
other teachers (in a friendly give and take way), more than trying to
tell them their jobs -- it's more fun that way, and way more
productive.

Kirby

From Scott.Daniels at Acm.Org  Tue Oct  3 06:50:54 2006
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Mon, 02 Oct 2006 21:50:54 -0700
Subject: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
In-Reply-To: <f604188c0610021812j47c7a1fey72cb9c43f7553916@mail.gmail.com>
References: <mailman.7.1159783202.5832.edu-sig@python.org>	<20061002161448.4A87B1E400B@bag.python.org>	<f604188c0610021000x2b601c69r52c82b88e6aa27bc@mail.gmail.com>	<1159823572.29157.12.camel@localhost>	<f604188c0610021604r71d20a8dk4eb0cdc01c504978@mail.gmail.com>	<1159833737.806.15.camel@localhost>
	<f604188c0610021812j47c7a1fey72cb9c43f7553916@mail.gmail.com>
Message-ID: <efsq5h$pp3$1@sea.gmane.org>

kirby urner wrote:
> Scott mentioned our not being able to see how many handles a mug has,
> but with the sys module we can: ....
Perhaps I said that, but what I _meant_ was that you could see the
handles.  In my mind, at least, there is a huge difference between
seeing the handles (what is this value's name?) and knowing how
many there are.  I just don't know a nifty concrete-world analog
to that.  The Library of Congress idea (too flawed, I agree) was
neat because objects (books) could become "lost" without a librarian
noticing.  Then on  to: "Well, if there were a count, and, ......"

-- Scott David Daniels
Scott.Daniels at Acm.Org


From ianb at colorstudy.com  Tue Oct  3 18:46:37 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 03 Oct 2006 11:46:37 -0500
Subject: [Edu-sig] Fwd: [EuroPython] Children first and
	a	hole-in-the-wall
In-Reply-To: <f604188c0610022104nbf10051ycf9f302b020da9e@mail.gmail.com>
References: <7be3f35d0610021215x159f8eecja0b7d717c0cbd0fd@mail.gmail.com>	<13a83ca10610021327x124d877do3c1d8bc4184a73a7@mail.gmail.com>
	<f604188c0610022104nbf10051ycf9f302b020da9e@mail.gmail.com>
Message-ID: <452293ED.7040709@colorstudy.com>

kirby urner wrote:
> interesting to:
>> http://www.greenstar.org/butterflies/Hole-in-the-Wall.htm
>>
> 
> An experiment worth doing once I suppose.  Proves kids have natural
> ability that we mostly waste and squander.
> 
> They deserve real opportunities though, not holes in the wall.  Just
> like a Physicist to coldly treat them like guinea pigs.  Continuing
> this experiment is a waste of time, and cruel.
> 
> There are plenty of adults who could provide real guidance, lots of
> technological capability.

As he said in the article: the learning was very fast, but shallow and 
they weren't able to get past a certain barriers without guidance.  I 
thought the outcomes described were unsurprising but also interpreted 
well -- he neither dismissed the children's accomplishments, nor did he 
interpret them as more than what they were.  The myth that all children 
are naturally "computer geniuses" is based on the naive onlooker who 
doesn't understand the full depth of computers, and so misinterprets as 
mastery what is just fearless experimentation and active attempts to 
build mental models of the system.  But there's a great deal more to be 
learned and understood that does not come naturally, even if children 
can learn particular aspects of the system without intervention.

There's still something important to learn from this: there's a great 
deal that children can teach themselves or each other.  And I might add: 
complete understanding is not necessary to be functional.

> We have no excuse to be doing "experiments" on these children.  They
> should be given real opportunities.

This argument should not be used, ever.  It's a pathetic defeatist 
argument that because injustice -- economic, education, or otherwise -- 
exists *somewhere* that doing a little something, incomplete though it 
may be, is wrong or distracting or detracts from the "real" solution. 
That this basic pattern of critique is so common is what frustrates me 
so much about it.

In this case a guy set up computers, with no expectation of any return 
or attempt to manipulate, and let these children use those computers. 
That's the experiment, and that experiment was in no way condescending 
or coercive.  The children got whatever they wanted out of it.  So why 
the negativity?

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org

From kirby.urner at gmail.com  Tue Oct  3 18:49:54 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Tue, 3 Oct 2006 09:49:54 -0700
Subject: [Edu-sig] Python for Halloween
Message-ID: <f604188c0610030949l4d63663eha0c1adcfac8712ee@mail.gmail.com>

Something about using 'ghost' in place of 'self' in a Shell class
(allusion to anime as well).

Maybe I did something like this last year (having deja vu again).

But I'm realizing edu-sig is no longer a preferred venue for my
curriculum writing.

I'd rather huddle with MIT, Bruce Sherwood, Alan Kay and play
*against* Arthur's team.

Arthur, you make too many enemies too quickly and too easily.

Even more, I'm into my Portland Knowledge Lab (PKL) business (gotta
pay that rent today) and want to make lots of Python and Synergetics
teaching cartoons for HDTV (my Saturday Morning meme), with lots of
brand name sponsors.

But here is not the place to brainstorm in safety.  Too many prying
eyes and self-appointed kibbitzers.

So I'm actually resigning this time.  Don't expect me back any time
soon.  Probably won't be tracking either, at least not with any
frequency.

For me, it's a tilt towards private lists and closed source
development (not exclusively -- I'm still a big supporter of a strong
public sector).

I'm learning why open source is a bad idea sometimes.

I've talked to Stallman about this, though he probably doesn't
remember -- I was in his audience in Portland and asked about
situations when "they" simply *don't deserve* your best code.

But I think more it's a matter of not wanting to show unfinished work
(a big no no in Fuller's self discipline, according to 'Critical Path'
I think it was).

Kirby

From kirby.urner at gmail.com  Tue Oct  3 18:53:23 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Tue, 3 Oct 2006 09:53:23 -0700
Subject: [Edu-sig] Fwd: [EuroPython] Children first and a
	hole-in-the-wall
In-Reply-To: <452293ED.7040709@colorstudy.com>
References: <7be3f35d0610021215x159f8eecja0b7d717c0cbd0fd@mail.gmail.com>
	<13a83ca10610021327x124d877do3c1d8bc4184a73a7@mail.gmail.com>
	<f604188c0610022104nbf10051ycf9f302b020da9e@mail.gmail.com>
	<452293ED.7040709@colorstudy.com>
Message-ID: <f604188c0610030953v158c0d98y99b108fa0373ba23@mail.gmail.com>

> In this case a guy set up computers, with no expectation of any return
> or attempt to manipulate, and let these children use those computers.
> That's the experiment, and that experiment was in no way condescending
> or coercive.  The children got whatever they wanted out of it.  So why
> the negativity?
>

Because now people think they maybe need to do this over and over?

Gee, isn't that cute, little underfed kids with no logistical support
other than some "hole in the wall" have brilliant minds, who woulda
guessed it?

Disgusting.

*Of course* they have brilliant minds.  That's just how we come equipped.

Then the dumbing down begins.

Kirby

From pgries at cs.toronto.edu  Tue Oct  3 19:31:09 2006
From: pgries at cs.toronto.edu (Paul Gries)
Date: Tue, 3 Oct 2006 13:31:09 -0400
Subject: [Edu-sig] Edu-sig Digest, Vol 39, Issue 2
In-Reply-To: <efsq5h$pp3$1@sea.gmane.org>
References: <mailman.7.1159783202.5832.edu-sig@python.org>	<20061002161448.4A87B1E400B@bag.python.org>	<f604188c0610021000x2b601c69r52c82b88e6aa27bc@mail.gmail.com>	<1159823572.29157.12.camel@localhost>	<f604188c0610021604r71d20a8dk4eb0cdc01c504978@mail.gmail.com>	<1159833737.806.15.camel@localhost>
	<f604188c0610021812j47c7a1fey72cb9c43f7553916@mail.gmail.com>
	<efsq5h$pp3$1@sea.gmane.org>
Message-ID: <DB77995A-129C-4CFA-9A08-1D23B424F06D@cs.toronto.edu>

On Oct 3, 2006, at 12:50 AM, Scott David Daniels wrote:
> kirby urner wrote:
>> Scott mentioned our not being able to see how many handles a mug has,
>> but with the sys module we can: ....
> Perhaps I said that, but what I _meant_ was that you could see the
> handles.  In my mind, at least, there is a huge difference between
> seeing the handles (what is this value's name?) and knowing how
> many there are.  I just don't know a nifty concrete-world analog
> to that.  The Library of Congress idea (too flawed, I agree) was
> neat because objects (books) could become "lost" without a librarian
> noticing.  Then on  to: "Well, if there were a count, and, ......"

I use a street metaphor.  (Which is where some of the lingo comes  
from anyway, isn't it?)  As a quick summary, houses are areas in  
memory and each has a unique address; people (variables) know the  
house they live in; a person's value is just the address of their  
house; x = y makes x live in the same house as y, and they can  
rummage in each other's personal belongings; deep copies are a lot of  
work; the contents of a house are accessible only to people who have  
the address; the number of people living in a house isn't immediately  
obvious; and when everybody moves out of the house, all the leftover  
stuff gets garbage collected.

Oh, and if you've talked about hardware at all you can make jokes  
about carrying things about on the bus.

Other similar things I've tried: warehouses with storage locations,  
apartment buildings, and offices.  Those didn't seem to work as well,  
but I tried them early on before I settled on streets; maybe they'd  
work out better today.

--
Paul Gries
Senior Lecturer, Dept. of Computer Science
University of Toronto




From ajsiegel at optonline.net  Wed Oct  4 04:58:36 2006
From: ajsiegel at optonline.net (Arthur)
Date: Tue, 03 Oct 2006 22:58:36 -0400
Subject: [Edu-sig] Python for Halloween
In-Reply-To: <f604188c0610030949l4d63663eha0c1adcfac8712ee@mail.gmail.com>
References: <f604188c0610030949l4d63663eha0c1adcfac8712ee@mail.gmail.com>
Message-ID: <4523235C.9070100@optonline.com>

kirby urner wrote:

> Arthur, you make too many enemies too quickly and too easily.

Nah, just making friends the hard way.

>
> But I think more it's a matter of not wanting to show unfinished work
> (a big no no in Fuller's self discipline, according to 'Critical Path'
> I think it was).

To be finished it will need a beginning, a middle and an end.  Not sure 
you have it in you. 

Easier  - just declare that concept obsolete.

Art


From jasonic at nomadics.org  Fri Oct  6 06:23:31 2006
From: jasonic at nomadics.org (Jason Cunliffe)
Date: Fri, 06 Oct 2006 06:23:31 +0200
Subject: [Edu-sig] Google Code Search
Message-ID: <4525DA43.70504@nomadics.org>

http://www.google.com/codesearch

http://code.google.com/

*http://blogs.zdnet.com/BTL/?p=3729*


From ajsiegel at optonline.net  Fri Oct  6 14:32:03 2006
From: ajsiegel at optonline.net (Arthur)
Date: Fri, 06 Oct 2006 08:32:03 -0400
Subject: [Edu-sig] The fate of vpython
Message-ID: <45264CC3.7050701@optonline.com>

This from the August 10 announcement of VPython 4.0beta5

"""

In the "Recent developments" section of vpython.org you can read a 
summary of the new features, which is also included in the documentation 
contained in the release. This includes a description of remaining known 
bugs, some of which are serious, which means that you may enjoy playing 
with the exciting new features, but be aware that there are problems.

I am not going to be able to do any more work on VPython for about three 
months, as the publisher of the physics textbook Ruth Chabay and I have 
written needs a second edition completed by November. Jonathan 
Brandmeyer has graduated from NCSU and is moving on to other things. So 
unless someone else steps forward, it is possible that this version 4 
beta is frozen for several months.

Bruce Sherwood
""" 

Essentially it reads to me that the 4.xxx branch of vpython is in some netherworld and, probably, deep trouble, with 
serious bugs, and no developer.

Don't know what Bruce's plan might be after completing his textbook work, but I think he would acknowledge that 
he's not the guy to do the hands-on development work to put things back on track.  Problem is, neither am I.

But I will try to begin to take this bull by the horns, as time allows.

My plan at the moment is to try to fork from the latest stable 3.xxx branch, with the initial goal of 
making it Numpy compatible.  As Numpy approaches final 1.0 release as the standard for array processing in
Python, it seems to me that a package such as vpython *needs* to work to support it if it is to survive.
If it  doesn't survive there is a serious hole in the Python educational world, IMO.

Serious educational projects are already suffering from this lack of compatibility.

See "The World is Your Python" 

http://www.physics.cornell.edu/~myers/teaching/ComputationalMethods/python/WorldPy.html


related to a Cornell U graduate physics course

"""
Computational Methods for Nonlinear Systems

This course is a graduate computer laboratory, emphasizing hands-on 
programming with a variety of data structures and algorithms. We focus 
on the next generation of tools for computation, simulation, and 
research in a broad range of fields
"""

where vpython is among the required packages, but where they face:

"""
The current version of VPython, however, is built on top of the older 
Numeric package, and seems a bit fussy when used in conjunction with 
the newer NumPy.
"""

"Fussy" I think being a bit of an understatement

I have gotten as far as to set up my ubuntu environment with necessary dev libraries for building against Python2.5
- boost, gtk2, gtkglarea,etc. and atc. and began to explore the .cpp moudles related to Numeric compatibility.

It would be great to see something concrete come out of all this edu-sig chaos, brainstorming, bickering and worse.

So I would prefer to see this fork of vpython from 3.xxx live as a community project, with *real* C developers involved, 
rather than myself learning as I go and perhaps quickly finding myself over my head and throwing up my hands.

Any interest out there??

Art








From dcrosta at sccs.swarthmore.edu  Fri Oct  6 14:55:55 2006
From: dcrosta at sccs.swarthmore.edu (Dan Crosta)
Date: Fri, 6 Oct 2006 08:55:55 -0400
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <45264CC3.7050701@optonline.com>
References: <45264CC3.7050701@optonline.com>
Message-ID: <326CC8DA-476D-4148-83EA-022635B23019@sccs.swarthmore.edu>

I don't know much about VPython or NumPy, but I've been involved in  
both contributing to and forking open source projects, from both  
sides, and I would caution against forking a project unless you're  
planning to take it in a new direction, or if there's some other  
compelling reason not to continue contributing from the main branch.

If the author of VPython is not planning to work on it for several  
months and you aren't planning to do anything other than make it  
compatible with a soon-to-be released version of one of its  
dependencies (is that the relationship b/w VPython and NumPy?), then  
why not carry on work from 4.0b5? Surely the dev will welcome any  
contributions which reduce work he'd later have to do anyway. He may  
even be willing to give you write access to the repository if you can  
demonstrate to him your willingness to work hard and ability to rally  
the troops of that class at Cornell.

This way you avoid duplication of work, since the VPython devs will  
neither have to duplicate your compatibility patches nor port your  
patches from 3.x to 4.0. The community is almost always better served  
by contribution than by forking, IMO.

- d


On Oct 6, 2006, at 8:32 AM, Arthur wrote:

> This from the August 10 announcement of VPython 4.0beta5
>
> """
>
> In the "Recent developments" section of vpython.org you can read a
> summary of the new features, which is also included in the  
> documentation
> contained in the release. This includes a description of remaining  
> known
> bugs, some of which are serious, which means that you may enjoy  
> playing
> with the exciting new features, but be aware that there are problems.
>
> I am not going to be able to do any more work on VPython for about  
> three
> months, as the publisher of the physics textbook Ruth Chabay and I  
> have
> written needs a second edition completed by November. Jonathan
> Brandmeyer has graduated from NCSU and is moving on to other  
> things. So
> unless someone else steps forward, it is possible that this version 4
> beta is frozen for several months.
>
> Bruce Sherwood
> """
>
> Essentially it reads to me that the 4.xxx branch of vpython is in  
> some netherworld and, probably, deep trouble, with
> serious bugs, and no developer.
>
> Don't know what Bruce's plan might be after completing his textbook  
> work, but I think he would acknowledge that
> he's not the guy to do the hands-on development work to put things  
> back on track.  Problem is, neither am I.
>
> But I will try to begin to take this bull by the horns, as time  
> allows.
>
> My plan at the moment is to try to fork from the latest stable  
> 3.xxx branch, with the initial goal of
> making it Numpy compatible.  As Numpy approaches final 1.0 release  
> as the standard for array processing in
> Python, it seems to me that a package such as vpython *needs* to  
> work to support it if it is to survive.
> If it  doesn't survive there is a serious hole in the Python  
> educational world, IMO.
>
> Serious educational projects are already suffering from this lack  
> of compatibility.
>
> See "The World is Your Python"
>
> http://www.physics.cornell.edu/~myers/teaching/ComputationalMethods/ 
> python/WorldPy.html
>
>
> related to a Cornell U graduate physics course
>
> """
> Computational Methods for Nonlinear Systems
>
> This course is a graduate computer laboratory, emphasizing hands-on
> programming with a variety of data structures and algorithms. We focus
> on the next generation of tools for computation, simulation, and
> research in a broad range of fields
> """
>
> where vpython is among the required packages, but where they face:
>
> """
> The current version of VPython, however, is built on top of the older
> Numeric package, and seems a bit fussy when used in conjunction with
> the newer NumPy.
> """
>
> "Fussy" I think being a bit of an understatement
>
> I have gotten as far as to set up my ubuntu environment with  
> necessary dev libraries for building against Python2.5
> - boost, gtk2, gtkglarea,etc. and atc. and began to explore  
> the .cpp moudles related to Numeric compatibility.
>
> It would be great to see something concrete come out of all this  
> edu-sig chaos, brainstorming, bickering and worse.
>
> So I would prefer to see this fork of vpython from 3.xxx live as a  
> community project, with *real* C developers involved,
> rather than myself learning as I go and perhaps quickly finding  
> myself over my head and throwing up my hands.
>
> Any interest out there??
>
> Art
>
>
>
>
>
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>


From ajsiegel at optonline.net  Fri Oct  6 15:51:25 2006
From: ajsiegel at optonline.net (Arthur)
Date: Fri, 06 Oct 2006 09:51:25 -0400
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <326CC8DA-476D-4148-83EA-022635B23019@sccs.swarthmore.edu>
References: <45264CC3.7050701@optonline.com>
	<326CC8DA-476D-4148-83EA-022635B23019@sccs.swarthmore.edu>
Message-ID: <45265F5D.9020508@optonline.com>

Dan Crosta wrote:

>If the author of VPython is not planning to work on it for several  
>months
>
The situation is that the actual authors of vpython are gone, as in 
graduated, moved on with their lives...

Bruce is more an adminstrator/funder (through a NSF grant) of the project. 

Essentially there is no developer as such involved in the project at 
this point.  Which is why I am concerned.

> and you aren't planning to do anything other than make it  
>compatible with a soon-to-be released version of one of its  
>dependencies (is that the relationship b/w VPython and NumPy?), then  
>why not carry on work from 4.0b5? 
>
Because it is has "serious bugs", and I have no motivation to even try 
to address those serious bugs at this time since they are
less serious, to me, than the lack of NumPy compatibility.

And because it is more realistic that I, working alone, might be  able 
to get to the Numpy issue - less so thatI can get to the bugs. I assume 
forward
porting a Numpy fix would be a small issue - but, as I say, I am not 
counting on the 4.xxx branch getting revived and until it does I think it
is more important to keep the 3.xxx branch alive and healthy.

If nothing develops here I might take the route of trying to implore the 
scipy folks into taking some interest in the problem.  For them it might
represent only a few hours work to at least get the Numpy compatibility 
issue resolved.  In fact, moving the project under the scipy umbrella
might be just the thing.

Except only that as part of scipy it will perceived in its more serious 
aspect and the fact that it makes a great little toy for beginners to 
play with will
get lost..  This versality is what I think is so significant about the 
project, and why I have concerns as to its fate.

Art



Art


From jasonic at nomadics.org  Sat Oct  7 00:16:25 2006
From: jasonic at nomadics.org (Jason Cunliffe)
Date: Sat, 07 Oct 2006 00:16:25 +0200
Subject: [Edu-sig] Usign Python with VisAD
Message-ID: <4526D5B9.5020401@nomadics.org>


  Using Python with VisAD

http://www.ssec.wisc.edu/~tomw/visadtutor/



From jasonic at nomadics.org  Sat Oct  7 00:17:38 2006
From: jasonic at nomadics.org (Jason Cunliffe)
Date: Sat, 07 Oct 2006 00:17:38 +0200
Subject: [Edu-sig] VisAD Python Scripts
Message-ID: <4526D602.1090705@nomadics.org>

http://www.ssec.wisc.edu/~billh/README.python

From ajsiegel at optonline.net  Mon Oct  9 04:36:09 2006
From: ajsiegel at optonline.net (Arthur Siegel)
Date: Sun, 08 Oct 2006 22:36:09 -0400
Subject: [Edu-sig] Using Python as the "CS 1" programming language
Message-ID: <1160361369.568.4.camel@localhost>

Just wanted to make sure that appropriate folks were aware of Titus
Brown's request @:

http://ivory.idyll.org/blog/oct-06/python-in-cs-1

In short, he is in discussion with Michigan State regarding a faculty
position and teaching CS101 with Python has come up in those
discussions, and he is looking for folks who have done so.

Art


From john.zelle at wartburg.edu  Mon Oct  9 18:48:21 2006
From: john.zelle at wartburg.edu (John Zelle)
Date: Mon, 9 Oct 2006 11:48:21 -0500
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <45265F5D.9020508@optonline.com>
References: <45264CC3.7050701@optonline.com>
	<326CC8DA-476D-4148-83EA-022635B23019@sccs.swarthmore.edu>
	<45265F5D.9020508@optonline.com>
Message-ID: <200610091148.21337.john.zelle@wartburg.edu>

I am also very concerned about this situation, as I think VPython is a 
wonderful tool (to which I've contributed). Unfortunately, I'm not really in 
any position to help out, as I am already over-stretched with my current 
commitments. I also fear that my C++ skills have somewhat atrophied, and the 
whole "boostification" of that project apparently steepened the learning 
curve significantly. I spent a little time trying to get the current beta to 
build and was not able to accomplish that (dependency issues). 

There was some talk a while back (related to pata-pata) about doing a "VPython 
in Python" using the PyOpenGL bindings. If I were seriously considering doing 
something to "resurrect" VPython, I would definitely consider going that 
route. It feels to me like the current VPython infrastructure is growing 
brittle and risks becoming a dead-end. Hopefully I'm wrong and some folks 
will pick up the development (scipy would be a good crew). I'd hate to have 
this tool fall into irrelevance.

--John


On Friday 06 October 2006 8:51 am, Arthur wrote:
> Dan Crosta wrote:
> >If the author of VPython is not planning to work on it for several
> >months
>
> The situation is that the actual authors of vpython are gone, as in
> graduated, moved on with their lives...
>
> Bruce is more an adminstrator/funder (through a NSF grant) of the project.
>
> Essentially there is no developer as such involved in the project at
> this point.  Which is why I am concerned.
>
> > and you aren't planning to do anything other than make it
> >compatible with a soon-to-be released version of one of its
> >dependencies (is that the relationship b/w VPython and NumPy?), then
> >why not carry on work from 4.0b5?
>
> Because it is has "serious bugs", and I have no motivation to even try
> to address those serious bugs at this time since they are
> less serious, to me, than the lack of NumPy compatibility.
>
> And because it is more realistic that I, working alone, might be  able
> to get to the Numpy issue - less so thatI can get to the bugs. I assume
> forward
> porting a Numpy fix would be a small issue - but, as I say, I am not
> counting on the 4.xxx branch getting revived and until it does I think it
> is more important to keep the 3.xxx branch alive and healthy.
>
> If nothing develops here I might take the route of trying to implore the
> scipy folks into taking some interest in the problem.  For them it might
> represent only a few hours work to at least get the Numpy compatibility
> issue resolved.  In fact, moving the project under the scipy umbrella
> might be just the thing.
>
> Except only that as part of scipy it will perceived in its more serious
> aspect and the fact that it makes a great little toy for beginners to
> play with will
> get lost..  This versality is what I think is so significant about the
> project, and why I have concerns as to its fate.
>
> Art
>
>
>
> Art
>
> _______________________________________________
> 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  

From radenski at studypack.com  Mon Oct  9 19:00:55 2006
From: radenski at studypack.com (Atanas Radenski)
Date: Mon, 09 Oct 2006 10:00:55 -0700
Subject: [Edu-sig] Using Python as the "CS 1" programming language
In-Reply-To: <1160361369.568.4.camel@localhost>
References: <1160361369.568.4.camel@localhost>
Message-ID: <20061009100055.q918cbyvm04go8g0@webmail.studypack.com>

Quoting Arthur Siegel <ajsiegel at optonline.net>:
...
> In short, he is in discussion with Michigan State regarding a faculty
> position and teaching CS101 with Python has come up in those
> discussions, and he is looking for folks who have done so.

A partial list of schools using Python is posted here:

http://studypack.com/comp/mod/glossary/view.php?id=2835

If you use Python in CS1 or other types of courses and wish to include  
an entry in the above list, please go there and do it. Or email me and  
I will include an entry for you. I believe it is useful for the Python  
cause to maintain a current list of this type.

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

Quoting Arthur Siegel <ajsiegel at optonline.net>:

> Just wanted to make sure that appropriate folks were aware of Titus
> Brown's request @:
>
> http://ivory.idyll.org/blog/oct-06/python-in-cs-1
>
> In short, he is in discussion with Michigan State regarding a faculty
> position and teaching CS101 with Python has come up in those
> discussions, and he is looking for folks who have done so.
>
> Art
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>


From ajsiegel at optonline.net  Mon Oct  9 19:16:53 2006
From: ajsiegel at optonline.net (Arthur Siegel)
Date: Mon, 09 Oct 2006 13:16:53 -0400
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <200610091148.21337.john.zelle@wartburg.edu>
References: <45264CC3.7050701@optonline.com>
	<326CC8DA-476D-4148-83EA-022635B23019@sccs.swarthmore.edu>
	<45265F5D.9020508@optonline.com>
	<200610091148.21337.john.zelle@wartburg.edu>
Message-ID: <1160414213.3105.23.camel@localhost>

On Mon, 2006-10-09 at 11:48 -0500, John Zelle wrote:
> I am also very concerned about this situation, as I think VPython is a 
> wonderful tool (to which I've contributed).

Hi John -

Thanks for that concern.

If you are following the vpython list you see that I am digging into the
immediate issues.  I have no C++ skills to have atrophied, but - as I
said there  - getting an understanding of building Python extensions has
been on my agenda and something concrete to dig into helps, so that I am
having some fun with it.  

But I agree that for all the simplicity on the surface, there is more
complexity underneath than one would hope for. It had Dethe, for
example, throwing up his hands in trying a port to native Mac.

The project funding is over, so that only volunteer resources are
available to salvage it.

I agree with you that more radical strategy than following the current
path is probably necessary.

Py-OpenGL is itself moving to a ctypes implementation, and ctypes is now
in the core Python distribution.

Slight problem being that I have no understanding of what that means.
Intuition is that the best solution might be there, someplace.

Meantime I am getting more familiar with the current C++ code, so that I
should be in a position to contribute to a re-implementation, given a
strategy to do so.

But it is OTOH scary that as to the vpython list, I seem to be the guru
at the moment, since I certainly don't consider myself qualified to
think this through without folks with more low-level skills.

I am holding off to going the scipy list with things until I at least
can talk with some measure of intelligence - but I am still thinking
that is where the best hope might be.

Art




From delza at livingcode.org  Mon Oct  9 19:54:53 2006
From: delza at livingcode.org (Dethe Elza)
Date: Mon, 9 Oct 2006 10:54:53 -0700
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <1160414213.3105.23.camel@localhost>
References: <45264CC3.7050701@optonline.com>
	<326CC8DA-476D-4148-83EA-022635B23019@sccs.swarthmore.edu>
	<45265F5D.9020508@optonline.com>
	<200610091148.21337.john.zelle@wartburg.edu>
	<1160414213.3105.23.camel@localhost>
Message-ID: <BB5D5065-CF78-4C4B-8CB0-B8BFDC1AF68C@livingcode.org>

I agree with John, and will make a stronger statement that C++ and  
Boost are part of the problem, not part of the solution as far as  
future development of VPython goes.  I don't at this point have time  
to work on VPython (I've tried to get the V4 betas to compile on OS  
X, but they aren't even close, even with all the prerequisite  
libraries installed).  So I'm following this discussion with interest  
(both here on edu-sig and over on the vpython list).

I have two hopes for the future of VPython.  One is a more python- 
based extension mechanism, using Ctypes or Pyrex, possibly based on  
ctypes-PyOpenGL.  The problem with this is that Mike Fletcher, who is  
doing the ctypes-PyOpenGL work, says that initially the ctypes branch  
will be slower than the existing PyOpenGL (but easier to maintain,  
and eventually may be faster).  Jonathan Brandemeyer, the most recent  
maintainer of VPython, said that he did make some attempts to use  
PyOpenGL but found it to be too slow for VPython.  That's why I think  
Pyrex might be the way to go--it looks mostly like Python code, but  
lets you call C code inline to make more optomized calls into the  
OpenGL infrastructure.

My other hope for VPython would be to build it on a more capable 3D  
system, such as Ogre or Panda3D (Mike Fletcher keeps a large list of  
such systems: http://www.vrplumber.com/py3d.py).  In this scenario,  
VPython would be an easier entry point into one of these more capable  
(and correspondingly more complex) systems, an Ogre-lite so to  
speak.  This would create a new dependency on an external library,  
which is bad, but may give VPython better evolutionary legs, which  
would be good.  My measure of how likely this scenario is, is based  
on having one of the scenegraph tools Just Work for the three main  
platforms (Windows, Linux, OS X), and that hasn't happened yet.

There is so much of interest going on in the 3D world right now, with  
good working systems finally available for X3D[1], open-source tools  
to build 3D avatars for Second Life[2], machinima systems[3], and  
tools like Google SketchUp[4] making 3D accessible to anyone who is  
interested.  It is sad to see VPython atrophy right now, but I'm sure  
that the ideas in it will find a home somewhere, whether the code  
does or not.

[1] http://www.web3d.org/
[2] http://www.avimator.com/
[3] http://orange.blender.org/

--Dethe

On 9-Oct-06, at 10:16 AM, Arthur Siegel wrote:

> On Mon, 2006-10-09 at 11:48 -0500, John Zelle wrote:
>> I am also very concerned about this situation, as I think VPython  
>> is a
>> wonderful tool (to which I've contributed).
>
> Hi John -
>
> Thanks for that concern.
>
> If you are following the vpython list you see that I am digging  
> into the
> immediate issues.  I have no C++ skills to have atrophied, but - as I
> said there  - getting an understanding of building Python  
> extensions has
> been on my agenda and something concrete to dig into helps, so that  
> I am
> having some fun with it.
>
> But I agree that for all the simplicity on the surface, there is more
> complexity underneath than one would hope for. It had Dethe, for
> example, throwing up his hands in trying a port to native Mac.
>
> The project funding is over, so that only volunteer resources are
> available to salvage it.
>
> I agree with you that more radical strategy than following the current
> path is probably necessary.
>
> Py-OpenGL is itself moving to a ctypes implementation, and ctypes  
> is now
> in the core Python distribution.
>
> Slight problem being that I have no understanding of what that means.
> Intuition is that the best solution might be there, someplace.
>
> Meantime I am getting more familiar with the current C++ code, so  
> that I
> should be in a position to contribute to a re-implementation, given a
> strategy to do so.
>
> But it is OTOH scary that as to the vpython list, I seem to be the  
> guru
> at the moment, since I certainly don't consider myself qualified to
> think this through without folks with more low-level skills.
>
> I am holding off to going the scipy list with things until I at least
> can talk with some measure of intelligence - but I am still thinking
> that is where the best hope might be.
>
> Art
>
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig


There are two ways of constructing a software design.  One way is to  
make it so simple there are obviously no deficiencies and the other  
way is to make it so complicated that there are no obvious  
deficiencies.  --C.A.R. Hoare



From ajsiegel at optonline.net  Mon Oct  9 20:15:24 2006
From: ajsiegel at optonline.net (Arthur Siegel)
Date: Mon, 09 Oct 2006 14:15:24 -0400
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <BB5D5065-CF78-4C4B-8CB0-B8BFDC1AF68C@livingcode.org>
References: <45264CC3.7050701@optonline.com>
	<326CC8DA-476D-4148-83EA-022635B23019@sccs.swarthmore.edu>
	<45265F5D.9020508@optonline.com>
	<200610091148.21337.john.zelle@wartburg.edu>
	<1160414213.3105.23.camel@localhost>
	<BB5D5065-CF78-4C4B-8CB0-B8BFDC1AF68C@livingcode.org>
Message-ID: <1160417725.5057.23.camel@localhost>

On Mon, 2006-10-09 at 10:54 -0700, Dethe Elza wrote:
> I agree with John, and will make a stronger statement that C++ and  
> Boost are part of the problem, not part of the solution as far as  
> future development of VPython goes.  

But...and about the only but I can think of...

One of the beauties of the current distro is that one can inherit the
exposed C++ classes - i.e. one can inherit and extend cvisual.sphere in
a Python class.  Hate to see that go away, in large part because of its
pedagogical value. And impression is that this feature would be
difficult to preserve with another extension mechanism.  But its mostly
an impression.

> Jonathan Brandemeyer, the most recent  
> maintainer of VPython, said that he did make some attempts to use  
> PyOpenGL but found it to be too slow for VPython.  That's why I think  
> Pyrex might be the way to go

> --it looks mostly like Python code, but  
> lets you call C code inline to make more optomized calls into the  
> OpenGL infrastructure.
> 

You may be right.  Recently came across a major 3d game engine which had
forked in the direction of a pyrex solution.

> My other hope for VPython would be to build it on a more capable 3D  
> system, such as Ogre or Panda3D (Mike Fletcher keeps a large list of  
> such systems: http://www.vrplumber.com/py3d.py).  In this scenario,  
> VPython would be an easier entry point into one of these more capable  
> (and correspondingly more complex) systems, an Ogre-lite so to  
> speak.  

Here I finally get to strongly disagree.  Vpython IMO should remain
stand-alone, light-weight.  Please, please.

I also see it as a possible entry point to things like Ogre and Panda3d,
but that is on a cognitive level, not a technical level. 

As a component to something either high-level and more heavyweight, or
more low-level, I don't see a purpose to it. I doubt it does anything
that Panda3d can't already do, and certainly nothing OpenGL can't
already do.

Vpython should be a lesson in how much one can do with not that much.
Let folks outgrow it, before they move on to other tools. Not many will.

Otherwise cognitive overload.

Again I think of VPython as in fact the perfect visual extension to
Python - something (with effort) you can keep in your head at one time. 

Its that sweet spot in the middle that makes it right for students, and
string-theorists ;).

Art


> This would create a new dependency on an external library,  
> which is bad, but may give VPython better evolutionary legs, which  
> would be good.  My measure of how likely this scenario is, is based  
> on having one of the scenegraph tools Just Work for the three main  
> platforms (Windows, Linux, OS X), and that hasn't happened yet.



> There is so much of interest going on in the 3D world right now, with  
> good working systems finally available for X3D[1], open-source tools  
> to build 3D avatars for Second Life[2], machinima systems[3], and  
> tools like Google SketchUp[4] making 3D accessible to anyone who is  
> interested.  It is sad to see VPython atrophy right now, but I'm sure  
> that the ideas in it will find a home somewhere, whether the code  
> does or not.
> 
> [1] http://www.web3d.org/
> [2] http://www.avimator.com/
> [3] http://orange.blender.org/
> 
> --Dethe
> 
> On 9-Oct-06, at 10:16 AM, Arthur Siegel wrote:
> 
> > On Mon, 2006-10-09 at 11:48 -0500, John Zelle wrote:
> >> I am also very concerned about this situation, as I think VPython  
> >> is a
> >> wonderful tool (to which I've contributed).
> >
> > Hi John -
> >
> > Thanks for that concern.
> >
> > If you are following the vpython list you see that I am digging  
> > into the
> > immediate issues.  I have no C++ skills to have atrophied, but - as I
> > said there  - getting an understanding of building Python  
> > extensions has
> > been on my agenda and something concrete to dig into helps, so that  
> > I am
> > having some fun with it.
> >
> > But I agree that for all the simplicity on the surface, there is more
> > complexity underneath than one would hope for. It had Dethe, for
> > example, throwing up his hands in trying a port to native Mac.
> >
> > The project funding is over, so that only volunteer resources are
> > available to salvage it.
> >
> > I agree with you that more radical strategy than following the current
> > path is probably necessary.
> >
> > Py-OpenGL is itself moving to a ctypes implementation, and ctypes  
> > is now
> > in the core Python distribution.
> >
> > Slight problem being that I have no understanding of what that means.
> > Intuition is that the best solution might be there, someplace.
> >
> > Meantime I am getting more familiar with the current C++ code, so  
> > that I
> > should be in a position to contribute to a re-implementation, given a
> > strategy to do so.
> >
> > But it is OTOH scary that as to the vpython list, I seem to be the  
> > guru
> > at the moment, since I certainly don't consider myself qualified to
> > think this through without folks with more low-level skills.
> >
> > I am holding off to going the scipy list with things until I at least
> > can talk with some measure of intelligence - but I am still thinking
> > that is where the best hope might be.
> >
> > Art
> >
> >
> >
> > _______________________________________________
> > Edu-sig mailing list
> > Edu-sig at python.org
> > http://mail.python.org/mailman/listinfo/edu-sig
> 
> 
> There are two ways of constructing a software design.  One way is to  
> make it so simple there are obviously no deficiencies and the other  
> way is to make it so complicated that there are no obvious  
> deficiencies.  --C.A.R. Hoare
> 
> 


From ajsiegel at optonline.net  Mon Oct  9 22:28:25 2006
From: ajsiegel at optonline.net (Arthur Siegel)
Date: Mon, 09 Oct 2006 16:28:25 -0400
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <BB5D5065-CF78-4C4B-8CB0-B8BFDC1AF68C@livingcode.org>
References: <45264CC3.7050701@optonline.com>
	<326CC8DA-476D-4148-83EA-022635B23019@sccs.swarthmore.edu>
	<45265F5D.9020508@optonline.com>
	<200610091148.21337.john.zelle@wartburg.edu>
	<1160414213.3105.23.camel@localhost>
	<BB5D5065-CF78-4C4B-8CB0-B8BFDC1AF68C@livingcode.org>
Message-ID: <1160425705.9085.7.camel@localhost>

On Mon, 2006-10-09 at 10:54 -0700, Dethe Elza wrote:My other hope for
VPython would be to build it on a more capable 3D  
> system, such as Ogre or Panda3D (Mike Fletcher keeps a large list of  
> such systems: http://www.vrplumber.com/py3d.py).  In this scenario,  
> VPython would be an easier entry point into one of these more capable  
> (and correspondingly more complex) systems

Kirbyish thought -

For those students moving in the direction of Ogre and Panda3D (in my
view not necessarily a significant portion of those who might find
something like VPython fun and interesting, at any rate):

present VPython as a level to be beaten, with a definition of "beating
the level".  The fact that there is no way to get to the Level 2 without
beating Level 1 would be second nature to them. Beat VPython *and then*
we install Panda3D.  Should take them a few months of real work.
Minimum.


Art


From delza at livingcode.org  Mon Oct  9 22:59:48 2006
From: delza at livingcode.org (Dethe Elza)
Date: Mon, 9 Oct 2006 13:59:48 -0700
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <1160417725.5057.23.camel@localhost>
References: <45264CC3.7050701@optonline.com>
	<326CC8DA-476D-4148-83EA-022635B23019@sccs.swarthmore.edu>
	<45265F5D.9020508@optonline.com>
	<200610091148.21337.john.zelle@wartburg.edu>
	<1160414213.3105.23.camel@localhost>
	<BB5D5065-CF78-4C4B-8CB0-B8BFDC1AF68C@livingcode.org>
	<1160417725.5057.23.camel@localhost>
Message-ID: <671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>

On 9-Oct-06, at 11:15 AM, Arthur Siegel wrote:

>> My other hope for VPython would be to build it on a more capable 3D
>> system, such as Ogre or Panda3D (Mike Fletcher keeps a large list of
>> such systems: http://www.vrplumber.com/py3d.py).  In this scenario,
>> VPython would be an easier entry point into one of these more capable
>> (and correspondingly more complex) systems, an Ogre-lite so to
>> speak.
>
> Here I finally get to strongly disagree.  Vpython IMO should remain
> stand-alone, light-weight.  Please, please.

VPython is only lightweight conceptually.  Boost and C++ are not  
lightweight, in my book.  Again, I could only see it going this way  
if there was a library that was easy to install (so that VPython  
became easier to install than it is now), and that doesn't exist  
right now (not for the three main platforms).

All this is just hot air, since I really have nothing to do with how  
VPython goes.

> I also see it as a possible entry point to things like Ogre and  
> Panda3d,
> but that is on a cognitive level, not a technical level.

One interesting way would be to have a pure-python (on top of  
PyOpenGL?) VPython, and a higher performance VPython (maybe on Ogre),  
similarly to how there are now ElementTree (pure-python XML),  
cElementTree (higher performance), and lxml (same API as ElementTree,  
but really a portal to all the XML processing power of libxml and  
libxslt, i.e., much more powerful *and* higher performance).

> As a component to something either high-level and more heavyweight, or
> more low-level, I don't see a purpose to it. I doubt it does anything
> that Panda3d can't already do, and certainly nothing OpenGL can't
> already do.

No comparison with OpenGL, since VPython (and all the 3D libraries I  
know of) already build on OpenGL. They add scenegraphs and higher- 
level APIs, but it's all OpenGL underneath.

My dream would be to have a VPython that is as easy to learn as it is  
now, easier to install than it is now, and capable of growing with  
you for awhile.

But right now that's just a dream.

--Dethe


Lao-Tse  thought XML was verbose but  that did not matter because  
computers  will someday learn from poets. --unknown, via Jason Cunliffe




From ajsiegel at optonline.net  Mon Oct  9 23:40:23 2006
From: ajsiegel at optonline.net (Arthur Siegel)
Date: Mon, 09 Oct 2006 17:40:23 -0400
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>
References: <45264CC3.7050701@optonline.com>
	<326CC8DA-476D-4148-83EA-022635B23019@sccs.swarthmore.edu>
	<45265F5D.9020508@optonline.com>
	<200610091148.21337.john.zelle@wartburg.edu>
	<1160414213.3105.23.camel@localhost>
	<BB5D5065-CF78-4C4B-8CB0-B8BFDC1AF68C@livingcode.org>
	<1160417725.5057.23.camel@localhost>
	<671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>
Message-ID: <1160430023.13686.24.camel@localhost>

On Mon, 2006-10-09 at 13:59 -0700, Dethe Elza wrote:
> On 9-Oct-06, at 11:15 AM, Arthur Siegel wrote:
> 
> >> My other hope for VPython would be to build it on a more capable 3D
> >> system, such as Ogre or Panda3D (Mike Fletcher keeps a large list of
> >> such systems: http://www.vrplumber.com/py3d.py).  In this scenario,
> >> VPython would be an easier entry point into one of these more capable
> >> (and correspondingly more complex) systems, an Ogre-lite so to
> >> speak.
> >
> > Here I finally get to strongly disagree.  Vpython IMO should remain
> > stand-alone, light-weight.  Please, please.
> 
> VPython is only lightweight conceptually.  Boost and C++ are not  
> lightweight, in my book.  Again, I could only see it going this way  
> if there was a library that was easy to install (so that VPython  
> became easier to install than it is now), and that doesn't exist  
> right now (not for the three main platforms).
> 

Its challenging to *build*. On a Windows machine and on a Debian based
system - given a suitable binary distro - it *installs* like anything
else. Like butter. So far, we have maintainer or 2 incovenienced by the
build complexity, and nobody else - at least necessarily.

Python itself is out-of-business if you had to *build* it on Windows to
use it.

In the last day or two I have learned to build it on Linux, from scratch
- which means building bjam, building boost given multiple existing
Python versions on the machine, building Numeric, and building VPython.
I am also fairly confident I will solve the numpy compatibility issue in
due course.

I know you are a devoted Mac guy, and I know nothing about native Mac.
But it seems to me that were there the relatively minimal code necessary
- which someone has recently committed to undertake - to create the
drawing context for VPython on native Mac, it could be packaged and
installed like any other native app there as well.

So it seems to me you are overstating a case, by a long-shot - probably
seeing the situation from a Mac-centric point of view.

But I have this crazy idea - and its crazy only in execution, not in
concept - that a vpython *as part of the Python distribution* would
change the landscape some.  And I understand that the current dependency
chain makes that an impossibility.

One of my (not very realistic) goals is to see if I can begin to
understand some way to bring vpython into the fold of a normal Python
distribution build process.  Other then that, and assuming the Mac
matter eventually gets solved, I would probably have no reason to rock
the vpython boat much at all.  

I'm looking for a good fight ;) so would love to have vpython not
seriously considered for bad reasons, rather then for good ones.

So to me anything that doesn't move in the direction of making vpython
buildable with Python, in the normal course, is not of much use or
interest.  

It ain't really broke.

Art

> All this is just hot air, since I really have nothing to do with how  
> VPython goes.
> 
> > I also see it as a possible entry point to things like Ogre and  
> > Panda3d,
> > but that is on a cognitive level, not a technical level.
> 
> One interesting way would be to have a pure-python (on top of  
> PyOpenGL?) VPython, and a higher performance VPython (maybe on Ogre),  
> similarly to how there are now ElementTree (pure-python XML),  
> cElementTree (higher performance), and lxml (same API as ElementTree,  
> but really a portal to all the XML processing power of libxml and  
> libxslt, i.e., much more powerful *and* higher performance).
> 
> > As a component to something either high-level and more heavyweight, or
> > more low-level, I don't see a purpose to it. I doubt it does anything
> > that Panda3d can't already do, and certainly nothing OpenGL can't
> > already do.
> 
> No comparison with OpenGL, since VPython (and all the 3D libraries I  
> know of) already build on OpenGL. They add scenegraphs and higher- 
> level APIs, but it's all OpenGL underneath.
> 
> My dream would be to have a VPython that is as easy to learn as it is  
> now, easier to install than it is now, and capable of growing with  
> you for awhile.
> 
> But right now that's just a dream.
> 
> --Dethe
> 
> 
> Lao-Tse  thought XML was verbose but  that did not matter because  
> computers  will someday learn from poets. --unknown, via Jason Cunliffe
> 
> 
> 


From ianb at colorstudy.com  Tue Oct 10 00:10:29 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 09 Oct 2006 17:10:29 -0500
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <1160430023.13686.24.camel@localhost>
References: <45264CC3.7050701@optonline.com>	<326CC8DA-476D-4148-83EA-022635B23019@sccs.swarthmore.edu>	<45265F5D.9020508@optonline.com>	<200610091148.21337.john.zelle@wartburg.edu>	<1160414213.3105.23.camel@localhost>	<BB5D5065-CF78-4C4B-8CB0-B8BFDC1AF68C@livingcode.org>	<1160417725.5057.23.camel@localhost>	<671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>
	<1160430023.13686.24.camel@localhost>
Message-ID: <452AC8D5.50100@colorstudy.com>

Arthur Siegel wrote:
> Its challenging to *build*. On a Windows machine and on a Debian based
> system - given a suitable binary distro - it *installs* like anything
> else. Like butter. So far, we have maintainer or 2 incovenienced by the
> build complexity, and nobody else - at least necessarily.

In my experience build difficulties are a major hinderance to developer 
participation.  It's really (really!) worth figuring out build issues.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org

From ajsiegel at optonline.net  Tue Oct 10 01:11:18 2006
From: ajsiegel at optonline.net (Arthur Siegel)
Date: Mon, 09 Oct 2006 19:11:18 -0400
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <452AC8D5.50100@colorstudy.com>
References: <45264CC3.7050701@optonline.com>
	<326CC8DA-476D-4148-83EA-022635B23019@sccs.swarthmore.edu>
	<45265F5D.9020508@optonline.com>
	<200610091148.21337.john.zelle@wartburg.edu>
	<1160414213.3105.23.camel@localhost>
	<BB5D5065-CF78-4C4B-8CB0-B8BFDC1AF68C@livingcode.org>
	<1160417725.5057.23.camel@localhost>
	<671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>
	<1160430023.13686.24.camel@localhost> <452AC8D5.50100@colorstudy.com>
Message-ID: <1160435479.18493.14.camel@localhost>

On Mon, 2006-10-09 at 17:10 -0500, Ian Bicking wrote:

> In my experience build difficulties are a major hinderance to developer 
> participation.  It's really (really!) worth figuring out build issues.
> 

Not sure there is any getting around the fact that Boost is quirky - its
own (bjam) build mechanism, the way it installs (or doesn't) its
libraries,etc. It makes sense, standalone.  But it is its own world
view, and therefore its own learning curve.

Everything else is pretty vanilla on the VPython3.xx branch.  Things on
the 4.xxx trunk get somewhat worse, since the dependencies begin to get
pretty esoteric - getting us into things like gtkglextmm, the C++
compatible version of the gtkgl extension.

It seems to me that the real problems are in an area that one would
think would be simple - only a context for OpenGL to draw and which
responds to basic mouse events and which doesn't need to be able to do
much else.

Why not togl across platforms???


Art

 


From john.zelle at wartburg.edu  Tue Oct 10 01:41:03 2006
From: john.zelle at wartburg.edu (John Zelle)
Date: Mon, 9 Oct 2006 18:41:03 -0500
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>
References: <45264CC3.7050701@optonline.com>
	<1160417725.5057.23.camel@localhost>
	<671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>
Message-ID: <200610091841.03250.john.zelle@wartburg.edu>

On Monday 09 October 2006 3:59 pm, Dethe Elza wrote:
> On 9-Oct-06, at 11:15 AM, Arthur Siegel wrote:
> >> My other hope for VPython would be to build it on a more capable 3D
> >> system, such as Ogre or Panda3D (Mike Fletcher keeps a large list of
> >> such systems: http://www.vrplumber.com/py3d.py).  In this scenario,
> >> VPython would be an easier entry point into one of these more capable
> >> (and correspondingly more complex) systems, an Ogre-lite so to
> >> speak.
> >
> > Here I finally get to strongly disagree.  Vpython IMO should remain
> > stand-alone, light-weight.  Please, please.
>
> VPython is only lightweight conceptually.  Boost and C++ are not
> lightweight, in my book.  Again, I could only see it going this way
> if there was a library that was easy to install (so that VPython
> became easier to install than it is now), and that doesn't exist
> right now (not for the three main platforms).
>

Just curious, is PyOpenGL easy to install for both Mac and Windows? I know 
it's dead simple on most Linux distributions. I think it's pretty easy for 
Windows, but have no experience at all on the Mac.


> All this is just hot air, since I really have nothing to do with how
> VPython goes.
>
> > I also see it as a possible entry point to things like Ogre and
> > Panda3d,
> > but that is on a cognitive level, not a technical level.
>
> One interesting way would be to have a pure-python (on top of
> PyOpenGL?) VPython, and a higher performance VPython (maybe on Ogre),
> similarly to how there are now ElementTree (pure-python XML),
> cElementTree (higher performance), and lxml (same API as ElementTree,
> but really a portal to all the XML processing power of libxml and
> libxslt, i.e., much more powerful *and* higher performance).
>
> > As a component to something either high-level and more heavyweight, or
> > more low-level, I don't see a purpose to it. I doubt it does anything
> > that Panda3d can't already do, and certainly nothing OpenGL can't
> > already do.
>
> No comparison with OpenGL, since VPython (and all the 3D libraries I
> know of) already build on OpenGL. They add scenegraphs and higher-
> level APIs, but it's all OpenGL underneath.
>
> My dream would be to have a VPython that is as easy to learn as it is
> now, easier to install than it is now, and capable of growing with
> you for awhile.

This is the reason for my above question. If PyOpenGL is easy to install then 
something "pure Python" on top of that should also be easy. Supposedly that 
solution will be too slow. That may be, but I'm not absolutely convinced. If 
Johnathon tried to implement VPython in Python using the existing VPython 
approach, the result would certainly be too slow. When I was working on 
VPython, I was struck by how much work it does that could nowdays be turned 
over to the graphics card itself. VPython is (at least was) not very 
OpenGLish, even though the final engine is OGL.  In some of the VR work we're 
doing, we have models with over 200,000 polygons that render allowing for 
smooth real-time rotate and zoom all done in Python. A few hundred spheres 
should be a piece of cake. Maybe we can't dupicate the most intensive VPython 
applications, but it sure seems like we should be able to tackle the types of 
demos that come with VPython. 

Of course, this is all just hot air too. I would _love_ to work on this 
project, but I don't see when I'm going to have any time. So it's only a 
dream here as well.

--John


>
> But right now that's just a dream.
>
> --Dethe
>
>
> Lao-Tse  thought XML was verbose but  that did not matter because
> computers  will someday learn from poets. --unknown, via Jason Cunliffe

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

From ajsiegel at optonline.net  Tue Oct 10 01:56:03 2006
From: ajsiegel at optonline.net (Arthur Siegel)
Date: Mon, 09 Oct 2006 19:56:03 -0400
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <200610091841.03250.john.zelle@wartburg.edu>
References: <45264CC3.7050701@optonline.com>
	<1160417725.5057.23.camel@localhost>
	<671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>
	<200610091841.03250.john.zelle@wartburg.edu>
Message-ID: <1160438163.19925.6.camel@localhost>

On Mon, 2006-10-09 at 18:41 -0500, John Zelle wrote:

> Just curious, is PyOpenGL easy to install for both Mac and Windows? I know 
> it's dead simple on most Linux distributions. I think it's pretty easy for 
> Windows, but have no experience at all on the Mac.

Assuming that PyOpenGL *is* easy to install, we come back to the same
question - an OpenGL windowing context, be it pygame, be it wxWindows,
be it togl, be it gtkgl, be it whatever one does on Mac.  PyOpenGL
provides the functionality, given a windowing context, not the windowing
context.

And since much of the cross-platform complexity of vpython is on the
windowing context issue, I see that solving that issue for vpython is a
more direct approach to solving the problem. But again, to me vpython
begins to lose its charm if we have to assume wxPython installed, or
pygame installed, or Panda3d installed.


Togl across platforms???

Art




From john.zelle at wartburg.edu  Tue Oct 10 04:02:46 2006
From: john.zelle at wartburg.edu (John Zelle)
Date: Mon, 9 Oct 2006 21:02:46 -0500
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <1160438163.19925.6.camel@localhost>
References: <45264CC3.7050701@optonline.com>
	<200610091841.03250.john.zelle@wartburg.edu>
	<1160438163.19925.6.camel@localhost>
Message-ID: <200610092102.46305.john.zelle@wartburg.edu>

On Monday 09 October 2006 6:56 pm, Arthur Siegel wrote:
> On Mon, 2006-10-09 at 18:41 -0500, John Zelle wrote:
> > Just curious, is PyOpenGL easy to install for both Mac and Windows? I
> > know it's dead simple on most Linux distributions. I think it's pretty
> > easy for Windows, but have no experience at all on the Mac.
>
> Assuming that PyOpenGL *is* easy to install, we come back to the same
> question - an OpenGL windowing context, be it pygame, be it wxWindows,
> be it togl, be it gtkgl, be it whatever one does on Mac.  PyOpenGL
> provides the functionality, given a windowing context, not the windowing
> context.

Right. But VPython really requires very little in the way of windowing 
context. I was thinking that GLUT (available by default in every OpenGL 
platform I've ever run across) would be sufficient. If PyOpenGL runs, GLUT is 
probably available.  I have no idea off the top of my head whether a PyOpenGL 
+ GLUT implementation of VPython is possible. To me, the main worry is how 
threading works across platforms.

>
> And since much of the cross-platform complexity of vpython is on the
> windowing context issue, I see that solving that issue for vpython is a
> more direct approach to solving the problem. But again, to me vpython
> begins to lose its charm if we have to assume wxPython installed, or
> pygame installed, or Panda3d installed.
>
>
> Togl across platforms???

Is Togl another dead end? Is anyone supporting it? Personally, I'm not all 
that excited with TK as a cross-platform solution anymore. It's been 
difficult to keep even my little graphics library stable on TK across 
Windows, Linux, and Mac.

--John

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

From davelist at mac.com  Tue Oct 10 13:29:26 2006
From: davelist at mac.com (davelist at mac.com)
Date: Tue, 10 Oct 2006 07:29:26 -0400
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <200610091841.03250.john.zelle@wartburg.edu>
References: <45264CC3.7050701@optonline.com>
	<1160417725.5057.23.camel@localhost>
	<671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>
	<200610091841.03250.john.zelle@wartburg.edu>
Message-ID: <D87207E7-7053-4C47-84CA-8F266B1378AC@mac.com>


On Oct 9, 2006, at 7:41 PM, John Zelle wrote:

> On Monday 09 October 2006 3:59 pm, Dethe Elza wrote:
>> On 9-Oct-06, at 11:15 AM, Arthur Siegel wrote:
>>>> My other hope for VPython would be to build it on a more capable 3D
>>>> system, such as Ogre or Panda3D (Mike Fletcher keeps a large  
>>>> list of
>>>> such systems: http://www.vrplumber.com/py3d.py).  In this scenario,
>>>> VPython would be an easier entry point into one of these more  
>>>> capable
>>>> (and correspondingly more complex) systems, an Ogre-lite so to
>>>> speak.
>>>
>>> Here I finally get to strongly disagree.  Vpython IMO should remain
>>> stand-alone, light-weight.  Please, please.
>>
>> VPython is only lightweight conceptually.  Boost and C++ are not
>> lightweight, in my book.  Again, I could only see it going this way
>> if there was a library that was easy to install (so that VPython
>> became easier to install than it is now), and that doesn't exist
>> right now (not for the three main platforms).
>>
>
> Just curious, is PyOpenGL easy to install for both Mac and Windows?  
> I know
> it's dead simple on most Linux distributions. I think it's pretty  
> easy for
> Windows, but have no experience at all on the Mac.
>


Someone has made binaries for it (and a number of other Python add- 
ons) at:

http://pythonmac.org/packages/py24-fat/index.html

It appears I also have pyopengl from fink.sf.net on my system.

I've used the "python setup.py install" method for some Python add- 
ons, but don't remember if I tried that on PyOpenGL.

Dave



From delza at livingcode.org  Tue Oct 10 18:26:42 2006
From: delza at livingcode.org (Dethe Elza)
Date: Tue, 10 Oct 2006 09:26:42 -0700
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <D87207E7-7053-4C47-84CA-8F266B1378AC@mac.com>
References: <45264CC3.7050701@optonline.com>
	<1160417725.5057.23.camel@localhost>
	<671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>
	<200610091841.03250.john.zelle@wartburg.edu>
	<D87207E7-7053-4C47-84CA-8F266B1378AC@mac.com>
Message-ID: <99F5AC37-ED6F-4699-97AD-732E7D1AEE9F@livingcode.org>

Dave wrote:

>> Just curious, is PyOpenGL easy to install for both Mac and  
>> Windows? I know
>> it's dead simple on most Linux distributions. I think it's pretty  
>> easy for
>> Windows, but have no experience at all on the Mac.
>
> Someone has made binaries for it (and a number of other Python add- 
> ons) at:
>
> http://pythonmac.org/packages/py24-fat/index.html

Which makes it as easy to install on OS X as on Windows.  Building it  
from source can be troublesome, but is far more tractable in my  
experience than VPython.

Art wrote:

> Assuming that PyOpenGL *is* easy to install, we come back to the same
> question - an OpenGL windowing context, be it pygame, be it wxWindows,
> be it togl, be it gtkgl, be it whatever one does on Mac.  PyOpenGL
> provides the functionality, given a windowing context, not the  
> windowing
> context.

One problem with VPython is that it lives in a world all its own,  
unlike most Python libraries.  PyOpenGL provides contexts for PyGame,  
for wx, and others (don't remember the whole list off-hand). If  
VPython (or VPython-lite) were built on PyOpenGL it would inherit all  
of these abilities.

> And since much of the cross-platform complexity of vpython is on the
> windowing context issue, I see that solving that issue for vpython  
> is a
> more direct approach to solving the problem. But again, to me vpython
> begins to lose its charm if we have to assume wxPython installed, or
> pygame installed, or Panda3d installed.

Well, there's assuming and there's assuring.  A binary installer for  
VPython could simply make sure the necessary dependencies are  
installed.  A setuptools-based build chain could do the same.

> Togl across platforms???

The last time someone (Joe Heafner) tried to tackle this on the  
VPython list, Bruce Sherwood replied:

> The fundamental issue has been discussed previously. Someone with Mac
> experience needs to write a small module to create a window and handle
> mouse and keyboard interactions. We have such modules for Windows and
> for Linux/Unix (alas, OpenGL doesn't provide this functionality).  
> In the
> absence of this native-mode window/interaction module, we have to limp
> along using the Unix version, which means using X11.

Since that is exactly what GLUT provides, and GLUT is available for  
every port of OpenGL that I'm aware of, I don't even know where to  
begin with such a comment.

The other issue with VPython portability is threading.  Instead of  
using Posix threads on Linux (which would *just work* on OS X), they  
pull in the gnome libraries for threading, adding an unneccesary  
dependency (in my opinion).  GLUT alone doesn't really help with  
that, but it could be a (huge) step in the right direction.

--Dethe

"Why is Virtual Reality always posited in terms of space, when time  
is the only real commodity left?" --Rich Gold



From ajsiegel at optonline.net  Wed Oct 11 00:54:12 2006
From: ajsiegel at optonline.net (ajsiegel at optonline.net)
Date: Tue, 10 Oct 2006 22:54:12 +0000 (GMT)
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <99F5AC37-ED6F-4699-97AD-732E7D1AEE9F@livingcode.org>
References: <45264CC3.7050701@optonline.com>
	<1160417725.5057.23.camel@localhost>
	<671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>
	<200610091841.03250.john.zelle@wartburg.edu>
	<D87207E7-7053-4C47-84CA-8F266B1378AC@mac.com>
	<99F5AC37-ED6F-4699-97AD-732E7D1AEE9F@livingcode.org>
Message-ID: <e3b8a0ea2e799.452c2494@optonline.net>



----- Original Message -----
From: Dethe Elza 
Date: Wednesday, October 11, 2006 1:28 am
Subject: Re: [Edu-sig] The fate of vpython
To: davelist at mac.com
Cc: edu-sig at python.org, John Zelle 

> Dave wrote:
> 
> >> Just curious, is PyOpenGL easy to install for both Mac and 
> >> Windows? I know
> >> it's dead simple on most Linux distributions. I think it's 
> pretty 
> >> easy for
> >> Windows, but have no experience at all on the Mac.
> >
> > Someone has made binaries for it (and a number of other Python 
> add- 
> > ons) at:
> >
> > http://pythonmac.org/packages/py24-fat/index.html
> 
> Which makes it as easy to install on OS X as on Windows. 
> Building it 
> from source can be troublesome, but is far more tractable in my 
> experience than VPython.

We agree that building VPython is a PITA, for those few who need to build it.

We agree it would be better if it were les of a pain.

But I somehow got myself in the postion of defending poor little vpython.

Not to easy for me, since its 400k in funding has run out, and one would think we
would just be enjoying it, rather than worrying about how to keep it alive - 400k
later.

You install pyopengl on the Mac.  What windowing system are you running it on???

The magic of vpython (in the good and bads sense ) - or the world-onto-itself 
aspect - is that once built it is in fact a world onto it self, i.e. self-sufficent.

And one can do only:

>>import visual
>>spehere()

and one has a sphere in a window, with the window responding to mouse events
in expected ways.

"Vpython" using pyopengl, in order to remain vpython, would need to recreate
that behevaior.  In order to recreate that behavior it would need to do so with
respect to specifc windowing systems.

I keep thinking we are going around in circles.

More and better crossplatform back-ends for vpython, we agree.

But there is baby and there is bathwater.

The need to go further than that, because we are using the words "build"
and "install" willynilly and polemically as we wish, can't see where we are 
trying to get to.

Doesn't one need swig installed to build pyopengl??

Vpython is used extensively by physics departments where their students
are not expected to have anything more than basic literacy re computers.

It is easy to install, needs to be, has to be.  There is a binary for Mac as well -
but it requires fink, so granted if you have toi install fink for no other reason than
to use vpython, vpython is not easy to install on the Mac.  But that is
more the norm than the exception for free and open source projects it 
seems to me.

The fact is that pygeo pre-dates vpython and was originally rendered directly by
pyopengl.  I went to vpython for many good reasons - but since I had already
done the pyopengl work, not becuase it was "easy", or at least not
only becuase it was easy,  It was certainly faster. But also its window
is smart - one zooms from very near to very far effortlessly, but there is
some design in that effortlessness. The ability to work from the interactive prompt,
without worrying about windowing code, etc.  That is what make vpython vpython.

vpython without its windowing code can't be vpython, and pyopengl does
solv a thing there, but make us slower, to the point of being unreasonably
slow for some of the kinds of things vpython needs to do to be vpython.

Glut.

Thought of that and rejected it on the "it seems to easy" grounds.

David Scherer, the orignal author of vpython, I think was looking for the
simplest solutions, and he came to the project as a game hacker, I believe.

Just a guess that if glut could have worked he would have wnet that way.

Maybe I am wrong.

I guess the answer is the right open source answer.  Whoever does the
work gets to call the shots.

Just hope it's somebody - not other then, but in addition to - me.

All this from the Internet lounge in Seoul, Korea airport.

Art

> 
> Art wrote:
> 
> > Assuming that PyOpenGL *is* easy to install, we come back to 
> the same
> > question - an OpenGL windowing context, be it pygame, be it 
> wxWindows,> be it togl, be it gtkgl, be it whatever one does on 
> Mac. PyOpenGL
> > provides the functionality, given a windowing context, not the 
> 
> > windowing
> > context.
> 
> One problem with VPython is that it lives in a world all its 
> own, 
> unlike most Python libraries. PyOpenGL provides contexts for 
> PyGame, 
> for wx, and others (don't remember the whole list off-hand). If 
> VPython (or VPython-lite) were built on PyOpenGL it would 
> inherit all 
> of these abilities.
> 
> > And since much of the cross-platform complexity of vpython is 
> on the
> > windowing context issue, I see that solving that issue for 
> vpython 
> > is a
> > more direct approach to solving the problem. But again, to me 
> vpython> begins to lose its charm if we have to assume wxPython 
> installed, or
> > pygame installed, or Panda3d installed.
> 
> Well, there's assuming and there's assuring. A binary installer 
> for 
> VPython could simply make sure the necessary dependencies are 
> installed. A setuptools-based build chain could do the same.
> 
> > Togl across platforms???
> 
> The last time someone (Joe Heafner) tried to tackle this on the 
> VPython list, Bruce Sherwood replied:
> 
> > The fundamental issue has been discussed previously. Someone 
> with Mac
> > experience needs to write a small module to create a window 
> and handle
> > mouse and keyboard interactions. We have such modules for 
> Windows and
> > for Linux/Unix (alas, OpenGL doesn't provide this 
> functionality). 
> > In the
> > absence of this native-mode window/interaction module, we have 
> to limp
> > along using the Unix version, which means using X11.
> 
> Since that is exactly what GLUT provides, and GLUT is available 
> for 
> every port of OpenGL that I'm aware of, I don't even know where 
> to 
> begin with such a comment.
> 
> The other issue with VPython portability is threading. Instead 
> of 
> using Posix threads on Linux (which would *just work* on OS X), 
> they 
> pull in the gnome libraries for threading, adding an unneccesary 
> 
> dependency (in my opinion). GLUT alone doesn't really help with 
> 
> that, but it could be a (huge) step in the right direction.
> 
> --Dethe
> 
> "Why is Virtual Reality always posited in terms of space, when 
> time 
> is the only real commodity left?" --Rich Gold
> 
> 
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
> 

From davelist at mac.com  Wed Oct 11 01:35:56 2006
From: davelist at mac.com (Dave Reed)
Date: Tue, 10 Oct 2006 19:35:56 -0400
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <e3b8a0ea2e799.452c2494@optonline.net>
References: <45264CC3.7050701@optonline.com>
	<1160417725.5057.23.camel@localhost>
	<671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>
	<200610091841.03250.john.zelle@wartburg.edu>
	<D87207E7-7053-4C47-84CA-8F266B1378AC@mac.com>
	<99F5AC37-ED6F-4699-97AD-732E7D1AEE9F@livingcode.org>
	<e3b8a0ea2e799.452c2494@optonline.net>
Message-ID: <463588DD-4D66-4904-B1B1-377719B42A32@mac.com>


On Oct 10, 2006, at 6:54 PM, ajsiegel at optonline.net wrote:

>
>
> ----- Original Message -----
> From: Dethe Elza
> Date: Wednesday, October 11, 2006 1:28 am
> Subject: Re: [Edu-sig] The fate of vpython
> To: davelist at mac.com
> Cc: edu-sig at python.org, John Zelle
>
>> Dave wrote:
>>
>>>> Just curious, is PyOpenGL easy to install for both Mac and
>>>> Windows? I know
>>>> it's dead simple on most Linux distributions. I think it's
>> pretty
>>>> easy for
>>>> Windows, but have no experience at all on the Mac.
>>>
>>> Someone has made binaries for it (and a number of other Python
>> add-
>>> ons) at:
>>>
>>> http://pythonmac.org/packages/py24-fat/index.html
>>
>> Which makes it as easy to install on OS X as on Windows.
>> Building it
>> from source can be troublesome, but is far more tractable in my
>> experience than VPython.
>

<snip>

>
> You install pyopengl on the Mac.  What windowing system are you  
> running it on???


It does need anything else - using glut it creates a native window on  
the Mac - it doesn't require X11.

<snip>

Dave




From ajsiegel at optonline.net  Wed Oct 11 01:44:54 2006
From: ajsiegel at optonline.net (ajsiegel at optonline.net)
Date: Tue, 10 Oct 2006 23:44:54 +0000 (GMT)
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <463588DD-4D66-4904-B1B1-377719B42A32@mac.com>
References: <45264CC3.7050701@optonline.com>
	<1160417725.5057.23.camel@localhost>
	<671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>
	<200610091841.03250.john.zelle@wartburg.edu>
	<D87207E7-7053-4C47-84CA-8F266B1378AC@mac.com>
	<99F5AC37-ED6F-4699-97AD-732E7D1AEE9F@livingcode.org>
	<e3b8a0ea2e799.452c2494@optonline.net>
	<463588DD-4D66-4904-B1B1-377719B42A32@mac.com>
Message-ID: <e331aedc29cb3.452c3076@optonline.net>



----- Original Message -----
From: Dave Reed 

> It does need anything else - using glut it creates a native 
> window on 
> the Mac - it doesn't require X11.

I assumed that it didn't require X11.

The question is what is the road to a glut window that has the capabilities
the the vpython window?

And if such a road exists, what would be the reason to not right it in
C intergrated with the existing vpython code, and exposed to Python.

By the other route vpython might end up being the first 3d application ever
prototyped in C and ported to Python ;)

Art



From delza at livingcode.org  Wed Oct 11 01:58:45 2006
From: delza at livingcode.org (Dethe Elza)
Date: Tue, 10 Oct 2006 16:58:45 -0700
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <e3b8a0ea2e799.452c2494@optonline.net>
References: <45264CC3.7050701@optonline.com>
	<1160417725.5057.23.camel@localhost>
	<671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>
	<200610091841.03250.john.zelle@wartburg.edu>
	<D87207E7-7053-4C47-84CA-8F266B1378AC@mac.com>
	<99F5AC37-ED6F-4699-97AD-732E7D1AEE9F@livingcode.org>
	<e3b8a0ea2e799.452c2494@optonline.net>
Message-ID: <1F65F5C0-25B7-4A03-871D-380243F01864@livingcode.org>

On 10-Oct-06, at 3:54 PM, ajsiegel at optonline.net wrote:

> You install pyopengl on the Mac.  What windowing system are you  
> running it on???

Simplest case, you run it using GLUT.  You also have the option to  
use wx, pygame, or Cocoa (native OS X).  In any of these cases, you  
do not need to install or run X windows.

> The magic of vpython (in the good and bads sense ) - or the world- 
> onto-itself
> aspect - is that once built it is in fact a world onto it self,  
> i.e. self-sufficent.
>
> And one can do only:
>
>>> import visual
>>> spehere()
>
> and one has a sphere in a window, with the window responding to  
> mouse events
> in expected ways.

I agree that anything which claims to be (or emulate) VPython would  
have to behave the same (and as simply).  No argument there, I'm afraid.

> "Vpython" using pyopengl, in order to remain vpython, would need to  
> recreate
> that behevaior.  In order to recreate that behavior it would need  
> to do so with
> respect to specifc windowing systems.

Yes.  On OS X today it VPython does not do that.

> Doesn't one need swig installed to build pyopengl??

I think you used to.  The ctypes-branch is quickly replacing the swig  
version, and ctypes is part of the python standard library as of  
Python 2.5.  I feel that ctypes is also easier to understand than  
either swig or boost, but maybe that's just me.

> Vpython is used extensively by physics departments where their  
> students
> are not expected to have anything more than basic literacy re  
> computers.
>
> It is easy to install, needs to be, has to be.  There is a binary  
> for Mac as well -
> but it requires fink, so granted if you have toi install fink for  
> no other reason than
> to use vpython, vpython is not easy to install on the Mac.  But  
> that is
> more the norm than the exception for free and open source projects it
> seems to me.

There is a series of steps you could use to build VPython using Fink  
that may or may not work anymore. The resulting VPython brings in  
lots of linux libraries and runs under X Windows (i.e., it neither  
looks, nor feels, nor runs like a native OS X application).  I'm not  
aware of any binary installer for this multistep process.  Despite OS  
X having a great OpenGL implementation (OpenGL is the basis for *all*  
graphics on OS X) and standards support, it is a second-class citizen  
in VPython's little world.

> The fact is that pygeo pre-dates vpython and was originally  
> rendered directly by
> pyopengl.  I went to vpython for many good reasons - but since I  
> had already
> done the pyopengl work, not becuase it was "easy", or at least not
> only becuase it was easy,  It was certainly faster. But also its  
> window
> is smart - one zooms from very near to very far effortlessly, but  
> there is
> some design in that effortlessness. The ability to work from the  
> interactive prompt,
> without worrying about windowing code, etc.  That is what make  
> vpython vpython.

No one is debating this.

> vpython without its windowing code can't be vpython, and pyopengl does
> solv a thing there, but make us slower, to the point of being  
> unreasonably
> slow for some of the kinds of things vpython needs to do to be  
> vpython.

Maybe.  I think a pure-python (which PyOpenGL-ctypes will be, relying  
on nothing outside of the standard library) version of VPython would  
be useful, even if you need to go to a C++ version of VPython for  
Really Big Models.

> Glut.
>
> Thought of that and rejected it on the "it seems to easy" grounds.
>
> David Scherer, the orignal author of vpython, I think was looking  
> for the
> simplest solutions, and he came to the project as a game hacker, I  
> believe.

A game hacker would likely dismiss Glut out of hand, because you  
would never use it for games.  You might use it for a windowing  
toolkit for physics students, though.  Perhaps there were other  
reasons for the VPython team not using Glut, so this is idle  
speculation.

> Just a guess that if glut could have worked he would have wnet that  
> way.
>
> Maybe I am wrong.
>
> I guess the answer is the right open source answer.  Whoever does the
> work gets to call the shots.

Again, I think there could reasonably be multiple implementations, if  
someone were willing to write the code.  It works for ElementTree/ 
cElementTree/lxml.  The VPython API is not all that complex, after all.

> Just hope it's somebody - not other then, but in addition to - me.

I keep hoping that too (somebody other than me), but it hasn't  
happened yet.  Once I clear a few other projects off my plate I will  
roll up my sleeves and try again.

> All this from the Internet lounge in Seoul, Korea airport.

Arriving or departing?

--Dethe

>
> Art
>
>>
>> Art wrote:
>>
>>> Assuming that PyOpenGL *is* easy to install, we come back to
>> the same
>>> question - an OpenGL windowing context, be it pygame, be it
>> wxWindows,> be it togl, be it gtkgl, be it whatever one does on
>> Mac. PyOpenGL
>>> provides the functionality, given a windowing context, not the
>>
>>> windowing
>>> context.
>>
>> One problem with VPython is that it lives in a world all its
>> own,
>> unlike most Python libraries. PyOpenGL provides contexts for
>> PyGame,
>> for wx, and others (don't remember the whole list off-hand). If
>> VPython (or VPython-lite) were built on PyOpenGL it would
>> inherit all
>> of these abilities.
>>
>>> And since much of the cross-platform complexity of vpython is
>> on the
>>> windowing context issue, I see that solving that issue for
>> vpython
>>> is a
>>> more direct approach to solving the problem. But again, to me
>> vpython> begins to lose its charm if we have to assume wxPython
>> installed, or
>>> pygame installed, or Panda3d installed.
>>
>> Well, there's assuming and there's assuring. A binary installer
>> for
>> VPython could simply make sure the necessary dependencies are
>> installed. A setuptools-based build chain could do the same.
>>
>>> Togl across platforms???
>>
>> The last time someone (Joe Heafner) tried to tackle this on the
>> VPython list, Bruce Sherwood replied:
>>
>>> The fundamental issue has been discussed previously. Someone
>> with Mac
>>> experience needs to write a small module to create a window
>> and handle
>>> mouse and keyboard interactions. We have such modules for
>> Windows and
>>> for Linux/Unix (alas, OpenGL doesn't provide this
>> functionality).
>>> In the
>>> absence of this native-mode window/interaction module, we have
>> to limp
>>> along using the Unix version, which means using X11.
>>
>> Since that is exactly what GLUT provides, and GLUT is available
>> for
>> every port of OpenGL that I'm aware of, I don't even know where
>> to
>> begin with such a comment.
>>
>> The other issue with VPython portability is threading. Instead
>> of
>> using Posix threads on Linux (which would *just work* on OS X),
>> they
>> pull in the gnome libraries for threading, adding an unneccesary
>>
>> dependency (in my opinion). GLUT alone doesn't really help with
>>
>> that, but it could be a (huge) step in the right direction.
>>
>> --Dethe
>>
>> "Why is Virtual Reality always posited in terms of space, when
>> time
>> is the only real commodity left?" --Rich Gold
>>
>>
>> _______________________________________________
>> Edu-sig mailing list
>> Edu-sig at python.org
>> http://mail.python.org/mailman/listinfo/edu-sig
>>


Art is either plagiarism or revolution. --Paul Gauguin



From ajsiegel at optonline.net  Wed Oct 11 02:39:24 2006
From: ajsiegel at optonline.net (ajsiegel at optonline.net)
Date: Wed, 11 Oct 2006 00:39:24 +0000 (GMT)
Subject: [Edu-sig] The fate of vpython
In-Reply-To: <1F65F5C0-25B7-4A03-871D-380243F01864@livingcode.org>
References: <45264CC3.7050701@optonline.com>
	<1160417725.5057.23.camel@localhost>
	<671C9258-8260-42B0-A304-FFFEC44C436D@livingcode.org>
	<200610091841.03250.john.zelle@wartburg.edu>
	<D87207E7-7053-4C47-84CA-8F266B1378AC@mac.com>
	<99F5AC37-ED6F-4699-97AD-732E7D1AEE9F@livingcode.org>
	<e3b8a0ea2e799.452c2494@optonline.net>
	<1F65F5C0-25B7-4A03-871D-380243F01864@livingcode.org>
Message-ID: <e1aae3a92a65e.452c3d3c@optonline.net>


From: Dethe Elza 
> 
> A game hacker would likely dismiss Glut out of hand, because you 

A glut and ctypes vpython.

Promise me a slot in the standard distrobution and I'll find a way to get there ;).

> Once I clear a few other projects off my plate I  will 
> roll up my sleeves and try again.

Can I hold you to that?

I figure you owe us a big gooey project by now.

Just because.  

> 
> Arriving or departing?

Actually on the way to Shanghai.  Decided I would be a better, calmer 
edu-sig citizen if I were filthy rich. So I am working on it.

Ralph Kramden  lives!

Guess that requires a cite these days:

http://www.museum.tv/archives/etv/H/htmlH/honeymooners/honeymooners.htm

Art
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20061011/991d11a5/attachment.htm 

From da.ajoy at gmail.com  Wed Oct 11 04:36:19 2006
From: da.ajoy at gmail.com (Daniel Ajoy)
Date: Tue, 10 Oct 2006 21:36:19 -0500
Subject: [Edu-sig] MIT sketching (Squeak on steroids?)
In-Reply-To: <e6acd7950610101935p1f3c8921vb28a46dff25cbd8a@mail.gmail.com>
References: <e6acd7950610101935p1f3c8921vb28a46dff25cbd8a@mail.gmail.com>
Message-ID: <e6acd7950610101936s5e067fe4v52cf20370e27a975@mail.gmail.com>

http://www.youtube.com/watch?v=NZNTgglPbUA


Daniel

From wescpy at gmail.com  Wed Oct 11 19:42:23 2006
From: wescpy at gmail.com (wesley chun)
Date: Wed, 11 Oct 2006 10:42:23 -0700
Subject: [Edu-sig] ANN: Advanced Python training course, Nov 8-10,
	San Francisco
In-Reply-To: <78b3a9580610111039hf332877ke9433cc0760143c6@mail.gmail.com>
References: <78b3a9580610111039hf332877ke9433cc0760143c6@mail.gmail.com>
Message-ID: <78b3a9580610111042w74a915e7m7a3676aec6f45829@mail.gmail.com>

FINAL REMINDER... we still have some seats left!

What:  Advanced Python Programming
When:  Nov 8-10 2006
Where: San Francisco (SFO/San Bruno), CA, USA

http://cyberwebconsulting.com (click on "Python Training")

This course, meant to follow our in-depth introduction class, adds new
tools to the Python programmer's toolkit. We explore advanced topics
such as: network programming with sockets, Internet clients, GUI
development, Web/CGI, databases/SQL, Extending Python with C, threads,
etc. Lectures and lab will get attendees comfortable developing
applications in these areas.

Come join us in beautiful Northern California for another rigorous
Python training event taught by software engineer, "Core Python
Programming" author, and technical instructor, Wesley Chun. This
course will take place in San Bruno right near the San Francisco
International Airport at the:

Staybridge Suites
San Francisco Airport
1350 Huntington Ave
San Bruno, CA  94066 USA
+1-650-588-0770

LOCALS: accessible from the entire Bay Area: parking + easy
101/280/380 access, across the street from San Bruno BART and up the
street from San Bruno CalTrain stations

VISITORS: free shuttle to/from the airport, lots of free food and wireless

The cost is $1295 per attendee. Discounts available for students and
teachers of secondary and post-secondary educational institutions. For
more information and registration, go to the website above.

2007 CALENDAR: Feb 7-9 (Intro), May 16-18 (Advanced), Aug 20-22 (Intro)

hope to see you in class!
-- wesley
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Core Python Programming", Prentice Hall, (c)2007,2001
    http://corepython.com

wesley.j.chun :: wescpy-at-gmail.com
python training and technical consulting
cyberweb.consulting : silicon valley, ca
http://cyberwebconsulting.com

From ajsiegel at optonline.net  Thu Oct 12 08:03:34 2006
From: ajsiegel at optonline.net (ajsiegel at optonline.net)
Date: Thu, 12 Oct 2006 06:03:34 +0000 (GMT)
Subject: [Edu-sig] The Fate of VPyton
Message-ID: <e742e1b22af89.452ddab6@optonline.net>


Did a litttle googling on the build issues...

enough to determine that projects using boost.python seem to be finding
that Scons makes the best alternative to a building mechanism of bjam, make or
some combination thereof.

For example:

http://mapnik.org/documentation/install/

Of course with the additional advantage that Scons is Python, so that 
whatever difficulties are posed, at least it is not learning a new syntax,
as someone like myself faces with make or bjam.  Willing to invest in
learning something about C++ and the Python C API.  Enough already.

So we are adding Scons build to the next, so far imaginary, generation of vpython.

"We" are?

Art
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20061012/f21e3913/attachment.html 

From jasonic at nomadics.org  Thu Oct 12 09:44:12 2006
From: jasonic at nomadics.org (Jason Cunliffe)
Date: Thu, 12 Oct 2006 09:44:12 +0200
Subject: [Edu-sig] The Fate of VPyton >> BLENDER ??
In-Reply-To: <e742e1b22af89.452ddab6@optonline.net>
References: <e742e1b22af89.452ddab6@optonline.net>
Message-ID: <452DF24C.10700@nomadics.org>

ajsiegel at optonline.net wrote:
> So we are adding Scons build to the next, so far imaginary, generation 
> of vpython.
>  
> "We" are?
>  
Art, I'm impressed by your determination...

Not knowing much about this at a code level, but I thinking more than 
ever that it may be a *really* good idea you look hard at Blender.
I've posted edu-sig several times previously, little or no feedback. No 
matter, but given the lengths you now seem to prepared to go to to 
rescue VPython, I'd be amazed if that effort might not be better applied 
to FIRST researching Blender, then perhaps brining your considerable 
skills to that table.
 
It's a sophisticated active platform to build upon - and it renders 
beautifully !

Lots of  "we" there -- good community including in France.

OpenGL,  cross platform, GPL license,
For many Blender-ers it's their determined creative auto-didact 
motivation to 'do stuff in 3D' that drags them into learning applied 
Python.
For example documentation help and recently a distributed network 
renderer :-)
Python is embedded in Blender. Plus GameKit and 3D web plug in [windows]

FEATURES
http://www.blender3d.org/cms/Features.155.0.html

FORUM
http://blenderartists.org/forum/forumdisplay.php?f=11

and much more..

good luck
Jason

From jasonic at nomadics.org  Thu Oct 12 10:08:00 2006
From: jasonic at nomadics.org (Jason Cunliffe)
Date: Thu, 12 Oct 2006 10:08:00 +0200
Subject: [Edu-sig] Uni-Verse  >> Edu-Verse ?
Message-ID: <452DF7E0.3080909@nomadics.org>

3 year EC [European Commission] funded project to "create an open source 
IP-based platform for multi-user, interactive, distributed, high-quality 
3D graphics and audio for home, public and personal use." [started 2004, 
grant budget 1.9 Million Euros]

Blender >> Python implicit
http://www.blender3d.org/cms/Newsitem.607+M5e406b7dff1.0.html

http://www.uni-verse.org/

There is surely an Edu-Sig follow-on EC grant waiting to be signed 2007 
for project seriously building on-top of Uni-Verse for open Edu 
applications and content.
Or perhaps even if extend/adapt Blender in more focused modern 
"educational" directions...

* Blender Conference 2006 ? 85.00
*Amsterdam, October 20-21-22
http://www.blender.org/e-shop/product_info.php?products_id=89

Jason

From jasonic at nomadics.org  Thu Oct 12 10:25:38 2006
From: jasonic at nomadics.org (Jason Cunliffe)
Date: Thu, 12 Oct 2006 10:25:38 +0200
Subject: [Edu-sig] OpenSG
Message-ID: <452DFC02.80801@nomadics.org>

OpenSG is a portable scenegraph system to create realtime graphics 
programs, e.g. for virtual reality applications. It is developed 
following Open Source principles (LGPL 
<http://www.gnu.org/licenses/lgpl.html>) and can be used freely. It runs 
on Windows, Linux, Solaris and MacOS X and is based on OpenGL 
<http://www.opengl.org/>.

http://opensg.vrsource.org/trac/wiki/WikiStart

From jasonic at nomadics.org  Thu Oct 12 10:31:18 2006
From: jasonic at nomadics.org (Jason Cunliffe)
Date: Thu, 12 Oct 2006 10:31:18 +0200
Subject: [Edu-sig] Python 3D Software Collection
Message-ID: <452DFD56.90602@nomadics.org>

A small collection (73 packages) of pointers to Python software for 
working in three dimensions

http://www.vrplumber.com/py3d.py

From ajsiegel at optonline.net  Fri Oct 13 06:48:31 2006
From: ajsiegel at optonline.net (ajsiegel at optonline.net)
Date: Fri, 13 Oct 2006 04:48:31 +0000 (GMT)
Subject: [Edu-sig] The Fate of VPyton >> BLENDER ??
In-Reply-To: <452DF24C.10700@nomadics.org>
References: <e742e1b22af89.452ddab6@optonline.net>
	<452DF24C.10700@nomadics.org>
Message-ID: <e459fd882bdb4.452f1a9f@optonline.net>

From: Jason Cunliffe 

> Not knowing much about this at a code level, but I thinking more 
> than 
> ever that it may be a *really* good idea you look hard at Blender.
> I've posted edu-sig several times previously, little or no 
> feedback. 

I have looked at Blender, and am aware - in broad terms - at the
strength of the surrounding community.  And have some across Blender
used in serious educational settings as well. 

It's just a different beast than vpython.  My commitment to vpython is in some
sense a commitment to lightweight simplicity where lightweight simplicity will do.

It's the same song I have been singing here from day one.

Maybe I am a moralist, puritan on these matters.  There is something
gluttonous, and in contradiction to the kind of principles we should be
promoting in an educational setting, by not emphasizing the just enough
to get the job done, and nothing more. And our tools should be
setting some example. Less *is* more would make a good norm,
with the exception to that rule needing to find a justification for itself.

Seems like we have migrated to the opposite of that way of thinking in
many ways.  I celebrate technology less than you do, I think, because
I hold it responsible for a good amount of this particular kind of damage.. 

There are solutions to limiting that damage, but damn it, none of them are 
themselves technology based. Which seems, almost by definition, to make 
them uninteresting, off-topic, anti-progressive, etc. When of course I see just the opposite being
true.  How did we get here? 

I am not contrarian just ot be so. Its coming from belief, and that belief
is coming from deep within my sensibility. I am stuck with my sensibility, but
have no reason to disrespect it. So that is the commitment I think you are 
seeing with me and vpython. And I am surprised you don't understand that
after hearing me spout off here for as long as I have.

The geometry with which I am fascinated is all about the universe of
exploration that can be done essentially limited to the concepts
"point", "line", "plane".  It  has kept me intellectually busy for some time, 
with some help from python, vpython, and a good deal of reading and a good deal of
working at it. 

Those tools are less than adequate for those exploring what exactly?

Art
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20061013/61e1c51e/attachment.htm 

From jasonic at nomadics.org  Fri Oct 13 11:04:12 2006
From: jasonic at nomadics.org (Jason Cunliffe)
Date: Fri, 13 Oct 2006 11:04:12 +0200
Subject: [Edu-sig] The Fate of VPyton >> BLENDER ??
In-Reply-To: <e459fd882bdb4.452f1a9f@optonline.net>
References: <e742e1b22af89.452ddab6@optonline.net>
	<452DF24C.10700@nomadics.org>
	<e459fd882bdb4.452f1a9f@optonline.net>
Message-ID: <452F568C.7060705@nomadics.org>

Art

Thanks for your clear reply..
Yes. Having a reasonable sense of your sensibilities from edu-sig 
dialogues, I hesitated 3 times before even suggesting it.

<personal memo>
I range wide in my sensibilities and preferences.
btw, I think I was perhaps the original poster to edu-sig about VPython.
Was greatly influenced by a magnificent shell+3D window  on Amiga c.1987 
called "PageRender3D". Am fairly sure you would approve highly of that one.
And then live GEOMETER implemented on SGI c.1993 [minimal and mind-blowing]
Or REBOL for example for its less-is-more philosophy. In general prefer 
one-to-one encounters than groups anytime. Signal to noise is usually so 
much better.
</personal memo>

However we are entering the great RW [read-write] cooperative, 
collaborative epoch. Ideas and process having many roots in the world of 
[Open]software, networks of networks, virtuality 
[modeling/simulation/contemplation...  in every order]
These dynamics are now bubbling up out into social financial and 
political spheres [ah see - Pure Geometry purifies]

meme-nets are thriving as never before

My subversive proposal to you is along those lines.
Optimistically,  I imagined that maybe a VPython version of Blender is 
quite possible AND a good idea.
The key paradigm is for a pure geometric minimal shell with live 3d 
viewer and modular architecture. small fast cheap beautiful user-controls

I think using the Blender Python API it is possible to configure Blender 
to run as shell based Geometry [Game] Engine.
You can ignore all the dancing  girls and singing seals if you want. 
What you gain however may be like a laboratory for geometry [with 
physics::: particles, light, gravity, etc]

Geometry meme -> Kepler elipses -> lead to orbiting planets.
or geometry behind this 
http://en.wikipedia.org/wiki/Image:Milky_Way_2005.jpg

And heres a video clip of experimental interface where minimal 2D 
geometry symbolizes physical mechanics
[draw = think = link] [ancient Greeks making marks in the sand with 
sticks seashells and string]
*
MIT live drawing*
http://www.youtube.com/watch?v=NZNTgglPbUA

Won't be surprised if you tell me that you love it OR hate it :-)

I understand why you don't want all the bells and whistles of Blender as 
it installs now.
But if it turned out that all that stuff was in proactive very easy to 
turn-off ,and instead present a VPython face.
Something installs well quickly cross-platform, how would you feel?

Jason

From john.zelle at wartburg.edu  Fri Oct 13 17:39:22 2006
From: john.zelle at wartburg.edu (John Zelle)
Date: Fri, 13 Oct 2006 10:39:22 -0500
Subject: [Edu-sig] The Fate of VPyton >> BLENDER ??
In-Reply-To: <452F568C.7060705@nomadics.org>
References: <e742e1b22af89.452ddab6@optonline.net>
	<e459fd882bdb4.452f1a9f@optonline.net>
	<452F568C.7060705@nomadics.org>
Message-ID: <200610131039.22379.john.zelle@wartburg.edu>

Jason,

I've looked into Blender a number of times, and while I would like to learn 
it, I have never had time for the learning curve. VPython is something my 
students and I can use immediately to solve problems at hand. If my goal were 
to become a 3D artist, then something like Blender would be the way to go.

You suggest some sort of "streamlined"  tool built on Blender is possible. But 
my recollection of Blender is that it embeds a Python intepreter, but is not 
itself a Python extension. If that is true, then I cannot use such a tool 
(even if streamlined) to augment _my_ Python environment. When I need  a 
quick 3D visualization for something I'm working on, I would have to 
somehow "import" all my work, libraries, etc. into this Blender-based 
environment. I just don't see Blender and VPython in the same "niche." 

If I am wrong about this, please let me know. Perhaps I have not looked hard 
enough, or perhaps Blender has changed since I last visited it.

--John


On Friday 13 October 2006 4:04 am, Jason Cunliffe wrote:
> Art
>
> Thanks for your clear reply..
> Yes. Having a reasonable sense of your sensibilities from edu-sig
> dialogues, I hesitated 3 times before even suggesting it.
>
> <personal memo>
> I range wide in my sensibilities and preferences.
> btw, I think I was perhaps the original poster to edu-sig about VPython.
> Was greatly influenced by a magnificent shell+3D window  on Amiga c.1987
> called "PageRender3D". Am fairly sure you would approve highly of that one.
> And then live GEOMETER implemented on SGI c.1993 [minimal and mind-blowing]
> Or REBOL for example for its less-is-more philosophy. In general prefer
> one-to-one encounters than groups anytime. Signal to noise is usually so
> much better.
> </personal memo>
>
> However we are entering the great RW [read-write] cooperative,
> collaborative epoch. Ideas and process having many roots in the world of
> [Open]software, networks of networks, virtuality
> [modeling/simulation/contemplation...  in every order]
> These dynamics are now bubbling up out into social financial and
> political spheres [ah see - Pure Geometry purifies]
>
> meme-nets are thriving as never before
>
> My subversive proposal to you is along those lines.
> Optimistically,  I imagined that maybe a VPython version of Blender is
> quite possible AND a good idea.
> The key paradigm is for a pure geometric minimal shell with live 3d
> viewer and modular architecture. small fast cheap beautiful user-controls
>
> I think using the Blender Python API it is possible to configure Blender
> to run as shell based Geometry [Game] Engine.
> You can ignore all the dancing  girls and singing seals if you want.
> What you gain however may be like a laboratory for geometry [with
> physics::: particles, light, gravity, etc]
>
> Geometry meme -> Kepler elipses -> lead to orbiting planets.
> or geometry behind this
> http://en.wikipedia.org/wiki/Image:Milky_Way_2005.jpg
>
> And heres a video clip of experimental interface where minimal 2D
> geometry symbolizes physical mechanics
> [draw = think = link] [ancient Greeks making marks in the sand with
> sticks seashells and string]
> *
> MIT live drawing*
> http://www.youtube.com/watch?v=NZNTgglPbUA
>
> Won't be surprised if you tell me that you love it OR hate it :-)
>
> I understand why you don't want all the bells and whistles of Blender as
> it installs now.
> But if it turned out that all that stuff was in proactive very easy to
> turn-off ,and instead present a VPython face.
> Something installs well quickly cross-platform, how would you feel?
>
> Jason
> _______________________________________________
> 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  

From ajsiegel at optonline.net  Sat Oct 14 04:41:20 2006
From: ajsiegel at optonline.net (ajsiegel at optonline.net)
Date: Sat, 14 Oct 2006 02:41:20 +0000 (GMT)
Subject: [Edu-sig] The Fate of VPyton >> BLENDER ??
In-Reply-To: <200610131039.22379.john.zelle@wartburg.edu>
References: <e742e1b22af89.452ddab6@optonline.net>
	<e459fd882bdb4.452f1a9f@optonline.net> <452F568C.7060705@nomadics.org>
	<200610131039.22379.john.zelle@wartburg.edu>
Message-ID: <e27be5f82b211.45304e50@optonline.net>

> On Friday 13 October 2006 4:04 am, Jason Cunliffe wrote:
> > My subversive proposal to you is along those lines.
> > Optimistically, I imagined that maybe a VPython version of 
> Blender is
> > quite possible AND a good idea.

Guess I am not seeing it.  Vpython needs compatibility with numpy, and a few
committed maintainers building distributions - Windows, deb, Mac X11 - and it
is a viable project.  A crossplatform windowing solution - like glut - would
bring Mac native into the fold, and make ongoing development/maintenance
easier.  Eliminating the boost dependency would have advantages, if not too much is sacrificed.  Either way,  move on with the 4.xxx branch that Jonathan had begun bringing
transparency, spot-lighting - etc. into the fold.

Again, I simply don't see it as that far off. The fact that the community
surrounding it is rather thin technically is its biggest vulnerability.  I can contribute
to trying to solve that by upgrading my own lower-level skills, and by trying to recruit
some interest by others who have those skills already. 

That's *my* plan.

The potential connection with blender I see is through the yafray rendering engine

www.yafray.org

wihich is connected to the blender project, but not exactly sure how.

Yafray is a high quality rendering engine with an XML scene description 
language.

It would be interesting if vpython could import and export from
Blender via this XML.

I had explored trying to implement this via PyGeo, but yafray XML is notoriously
underdocumented at this point.  If that improves, I would definititely try to
do something.  PyGeo already exports nicely to Pov-Ray, so the infrastructure to
do this kind of thing is already there. Would be relatively trivial to add the 
yafray XML alternative.  To me, among other things, it's just an excuse to get
hands on with XML functionality - but maybe it would lead to something
interesting.

> > MIT live drawing*
> > http://www.youtube.com/watch?v=NZNTgglPbUA

Don't have the bandwidth available to me to give it a look from
here. Hoepfully when I get back.


Art

From jeff at elkner.net  Tue Oct 17 02:14:55 2006
From: jeff at elkner.net (Jeffrey Elkner)
Date: Tue, 17 Oct 2006 00:14:55 +0000
Subject: [Edu-sig] Python in Education planning for PyCon 2007
In-Reply-To: 0
Message-ID: <20061017001455.26151.262552591.divmod.quotient.4334@ohm>

Hi All,

I've created a link off the PyCon 2007 wiki to use to help us plan for Python in education activities at the conference:

http://us.pycon.org/TX2007/PyEdu

Please add your name to the list on the page if you are coming.  Last year was a very productive one for Python in education.  Projects such as RUR-PLE and Crunchy Frog are providing more and better tools for teaching programming with Python.

In addition to the EDU BOF dinner we had last year, it would be great if we could have some presentations with a Python in education focus, and perhaps a few project planning meetings and work sessions as well.

I'll be bringing two students and a former student who is now a Zope 3 developer.  We will be staying for the first two days of the sprints to work on SchoolTool/CanDo.

Hope to see you at the conference...

jeff elkner

From andre.roberge at gmail.com  Tue Oct 17 03:05:10 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Mon, 16 Oct 2006 22:05:10 -0300
Subject: [Edu-sig] Python in Education planning for PyCon 2007
In-Reply-To: <20061017001455.26151.262552591.divmod.quotient.4334@ohm>
References: <20061017001455.26151.262552591.divmod.quotient.4334@ohm>
Message-ID: <7528bcdd0610161805u43387e9cj1310681ed9c8dcb9@mail.gmail.com>

I am hoping that I can find the time in my schedule to take a vacation
and join you all at PyCon 2007.  Of course, if I do,  I could give a
talk on RUR-PLE and Crunchy. ;-)

Thanks for creating that page and I will add my name if I can come; it
would be nice to meet "real" Python teachers and get some more ideas
to incorporate within Crunchy.

Andr?

On 10/16/06, Jeffrey Elkner <jeff at elkner.net> wrote:
> Hi All,
>
> I've created a link off the PyCon 2007 wiki to use to help us plan for Python in education activities at the conference:
>
> http://us.pycon.org/TX2007/PyEdu
>
> Please add your name to the list on the page if you are coming.  Last year was a very productive one for Python in education.  Projects such as RUR-PLE and Crunchy Frog are providing more and better tools for teaching programming with Python.
>
> In addition to the EDU BOF dinner we had last year, it would be great if we could have some presentations with a Python in education focus, and perhaps a few project planning meetings and work sessions as well.
>
> I'll be bringing two students and a former student who is now a Zope 3 developer.  We will be staying for the first two days of the sprints to work on SchoolTool/CanDo.
>
> Hope to see you at the conference...
>
> jeff elkner
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>

From simon at arrowtheory.com  Sun Oct 22 23:46:48 2006
From: simon at arrowtheory.com (Simon Burton)
Date: Sun, 22 Oct 2006 14:46:48 -0700
Subject: [Edu-sig] PyDX - announce
Message-ID: <20061022144648.bc95ec00.simon@arrowtheory.com>


Hi,

I'd like to let edu-sig know about this project I've been working on.
It is too under-documented to be really useful as an educational tool ATM, 
but a lot of the concepts behind the code are both simple to understand and deeply profound, mathematically.
Hence this post to edu-sig.

Check it out!

PyDX - first public announcement
================================

Overview
--------

    PyDX is a package for working with calculus (differential geometry),
arbitrary precision arithmetic (using gmpy), and interval arithmetic.

It provides:
    * multivariate automatic differentiation (to arbitrary order)
    * Tensor objects for computations in differential geometry
    * Interval scalars (based on libMPFI) for calculating rigorous bounds
on arithmetic operations (validated numerics).
    * Arbitrary order validated ODE solver.

PyDX uses lazy computation techniques to greatly enhance performance of
the resulting functions.

This code grew out of a research project at The Australian National University,
Department of Physics, which involved computing bounds on geodesics in 
relativistic space-time's.

Documentation
-------------

http://gr.anu.edu.au/svn/people/sdburton/pydx/doc/user-guide.html
http://gr.anu.edu.au/svn/people/sdburton/pydx/doc/api/index.html

Subversion Repository
---------------------

http://gr.anu.edu.au/svn/people/sdburton/pydx/


Simon Burton
October 22 2006
The Australian National University





From tjd at sfu.ca  Tue Oct 24 23:02:37 2006
From: tjd at sfu.ca (Toby Donaldson)
Date: Tue, 24 Oct 2006 14:02:37 -0700
Subject: [Edu-sig] python education search engine
Message-ID: <a2f565170610241402y34042ff6ye30a1ae8dfa1f19b@mail.gmail.com>

Hi all,

I am playing with the new Google "co-op" search engine feature, and
have created a Python education search engine:

http://www.google.com/coop/cse?cx=017583026537348134569%3Axorqs4uwyn4

Volunteers are welcome!

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

From sandysj at juno.com  Thu Oct 26 22:27:54 2006
From: sandysj at juno.com (Jeff Sandys)
Date: Thu, 26 Oct 2006 20:27:54 GMT
Subject: [Edu-sig] Accredited training for school teachers?
Message-ID: <20061026.132852.3420.1120142@webmail58.nyc.untd.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://mail.python.org/pipermail/edu-sig/attachments/20061026/aee3c72a/attachment.pot 

From ajsiegel at optonline.net  Mon Oct 30 14:28:58 2006
From: ajsiegel at optonline.net (Arthur)
Date: Mon, 30 Oct 2006 08:28:58 -0500
Subject: [Edu-sig] Truth values and comparisons
Message-ID: <4545FE1A.2060303@optonline.com>


Looking for a little education on edu-sig.

On one hand I am feeling like a big boy, having announced today on the 
vpython list that I think I have adequately accomplished the necessary 
fixes to the vpython C++ code to accomplish compatibility with the newly 
released numpy 1.0, and in a way that I think in the end (it was a 
round-about process for me)  is straightforward and unlikely to 
introduce bugs into the existing stable codebase.

OTOH, I am learning there is some very basic Python I do not understand.

Now having a vpython that runs against numpy, I am learning about some 
of the changes in the numpy Python API versus that of Numeric and 
numarray. One basic incompatibility is in that the older libraries did 
something to give a result in comparing 2 arrays that numpy backs away 
from - complaining about ambiguity.

For example, in the vpython faces_heightfield.py demo there is a line:

 >>>normal[i] = vertex_map[tp] and norm( vertex_map[ tp ] )

which ran fine under Numeric and numarray, and now fails with a message:

"""
The truth value of an array with more than one element is ambiguous.
Use a.any() or a.all()
"""

For the purposes of the exercise assume that both "vertex_map[tp]" and 
"norm( vertex_map[ tp ]"
each return one dimensional, 3 element numpy arrays. Not exactly true, 
but I think the result would be the same if it were.

In the original code, what is the "and" doing, and in what way might the 
"any" or "all" built-ins be used to get the result intended by it?


Art





From davelist at mac.com  Mon Oct 30 15:23:38 2006
From: davelist at mac.com (davelist at mac.com)
Date: Mon, 30 Oct 2006 06:23:38 -0800
Subject: [Edu-sig] Truth values and comparisons
In-Reply-To: <4545FE1A.2060303@optonline.com>
References: <4545FE1A.2060303@optonline.com>
Message-ID: <6B0E2998-010E-1000-CE84-18BA582E8EB6-Webmail-10011@mac.com>

 
On Monday, October 30, 2006, at 08:30AM, "Arthur" <ajsiegel at optonline.net> wrote:
>
>Looking for a little education on edu-sig.
>
>On one hand I am feeling like a big boy, having announced today on the 
>vpython list that I think I have adequately accomplished the necessary 
>fixes to the vpython C++ code to accomplish compatibility with the newly 
>released numpy 1.0, and in a way that I think in the end (it was a 
>round-about process for me)  is straightforward and unlikely to 
>introduce bugs into the existing stable codebase.
>
>OTOH, I am learning there is some very basic Python I do not understand.
>
>Now having a vpython that runs against numpy, I am learning about some 
>of the changes in the numpy Python API versus that of Numeric and 
>numarray. One basic incompatibility is in that the older libraries did 
>something to give a result in comparing 2 arrays that numpy backs away 
>from - complaining about ambiguity.
>
>For example, in the vpython faces_heightfield.py demo there is a line:
>
> >>>normal[i] = vertex_map[tp] and norm( vertex_map[ tp ] )
>
>which ran fine under Numeric and numarray, and now fails with a message:
>
>"""
>The truth value of an array with more than one element is ambiguous.
>Use a.any() or a.all()
>"""
>
>For the purposes of the exercise assume that both "vertex_map[tp]" and 
>"norm( vertex_map[ tp ]"
>each return one dimensional, 3 element numpy arrays. Not exactly true, 
>but I think the result would be the same if it were.
>
>In the original code, what is the "and" doing, and in what way might the 
>"any" or "all" built-ins be used to get the result intended by it?


I've not used .any or .all, but having just taught my CS1 students about boolean operators, I was reminded that Python works as the following example describes:

x = a and b
# if both a and b are true, x is assigned b, otherwise x is assigned a
x = 2 and 3 # x is assigned 3
x = 0 and 2 # x is assigned 0

x = a or b
# if a is true, x is assigned a, if a is true, x is assigned a, if a is false and b is true, x is assigned b, if both a and b are false, x is assigned False

You need to determine what should make vertex_map[tp] be true (maybe it is all the values being non-zero or maybe it is just the array being non-empty) and assuming norm is then a single floating point value, if it's non-zero, it is true. And then assign normal[i] the appropriate one.

HTH,
Dave


From ajsiegel at optonline.net  Mon Oct 30 17:49:02 2006
From: ajsiegel at optonline.net (Arthur)
Date: Mon, 30 Oct 2006 11:49:02 -0500
Subject: [Edu-sig] Truth values and comparisons
In-Reply-To: <6B0E2998-010E-1000-CE84-18BA582E8EB6-Webmail-10011@mac.com>
References: <4545FE1A.2060303@optonline.com>
	<6B0E2998-010E-1000-CE84-18BA582E8EB6-Webmail-10011@mac.com>
Message-ID: <45462CFE.2010100@optonline.com>

davelist at mac.com wrote:

>
>I've not used .any or .all, but having just taught my CS1 students about boolean operators, I was reminded that Python works as the following example describes:
>
>x = a and b
># if both a and b are true, x is assigned b, otherwise x is assigned a
>x = 2 and 3 # x is assigned 3
>x = 0 and 2 # x is assigned 0
>
>x = a or b
># if a is true, x is assigned a, if a is true, x is assigned a, if a is false and b is true, x is assigned b, if both a and b are false, x is assigned False
>
>You need to determine what should make vertex_map[tp] be true...
>
thanks, but having some trouble:

 >>> import Numeric as N
 >>> a=N.array([0,0,0])
 >>> b=N.array([0,0,1])
 >>> a and b
array([0, 0, 0])
 >>> b and  a
array([0, 0, 0])

Can this be?  Either both a and b are true, or they are not,  so can it 
be returning the "a" in both cases? Something screwy, other than my 
comprehension here?

Same problem with

 >>> a or b
array([0, 0, 1])
 >>> b or a
array([0, 0, 1])

OTOH, this makes sense to me - with "0" being False

 >>> any(a)
False
 >>> all(a)
False
 >>> any(b)
True
 >>> all(b)
False

Though anyone growing up with the Python boolean operator might wonder 
why it is as it is - i.e. when 0 was the way to spell False this 
behavior is fairly well expected.  Now that False is spelled "False", 
having "0" any less true than "1", when thinks one is dealing with 
numbers as numbers, is likely to catch the less geeky unaware, IMO.

Art




From john.zelle at wartburg.edu  Mon Oct 30 18:07:04 2006
From: john.zelle at wartburg.edu (John Zelle)
Date: Mon, 30 Oct 2006 11:07:04 -0600
Subject: [Edu-sig] Truth values and comparisons
In-Reply-To: <45462CFE.2010100@optonline.com>
References: <4545FE1A.2060303@optonline.com>
	<6B0E2998-010E-1000-CE84-18BA582E8EB6-Webmail-10011@mac.com>
	<45462CFE.2010100@optonline.com>
Message-ID: <200610301107.04522.john.zelle@wartburg.edu>

On Monday 30 October 2006 10:49 am, Arthur wrote:
> davelist at mac.com wrote:
> >I've not used .any or .all, but having just taught my CS1 students about
> > boolean operators, I was reminded that Python works as the following
> > example describes:
> >
> >x = a and b
> ># if both a and b are true, x is assigned b, otherwise x is assigned a
> >x = 2 and 3 # x is assigned 3
> >x = 0 and 2 # x is assigned 0
> >
> >x = a or b
> ># if a is true, x is assigned a, if a is true, x is assigned a, if a is
> > false and b is true, x is assigned b, if both a and b are false, x is
> > assigned False
> >
> >You need to determine what should make vertex_map[tp] be true...
>
> thanks, but having some trouble:
>  >>> import Numeric as N
>  >>> a=N.array([0,0,0])
>  >>> b=N.array([0,0,1])
>  >>> a and b
>
> array([0, 0, 0])

This tells me that a zero array is being treated as False (the logical 
extension to arrays of 0 being false. 
>
>  >>> b and  a
>
> array([0, 0, 0])

Right. In both cases, the answer is False, which Python gives to you by 
handing you the first False expression. In either case the false part of the 
and is the 0 array, while the other is True (a non-zero array).

You can check this out:

>>> not(a)
True

>>> not(b)
False

>
> Can this be?  Either both a and b are true, or they are not,  so can it
> be returning the "a" in both cases? Something screwy, other than my
> comprehension here?

Because a is False ;-). They're not both true.

> Same problem with
>
>  >>> a or b
>
> array([0, 0, 1])
>
>  >>> b or a
>
> array([0, 0, 1])
>

This works the same way, but returns the first True expression as the value 
of "True."

>  >>> any(a)
>
> False
>
>  >>> all(a)
>
> False
>
>  >>> any(b)
>
> True
>
>  >>> all(b)
>
> False
>
> Though anyone growing up with the Python boolean operator might wonder
> why it is as it is - i.e. when 0 was the way to spell False this
> behavior is fairly well expected.  Now that False is spelled "False",
> having "0" any less true than "1", when thinks one is dealing with
> numbers as numbers, is likely to catch the less geeky unaware, IMO.

This is why in teaching I prefer to use explicit tests:

if x != 0:
    do something

Rather than 

if x:
    do something

--John

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

From ajsiegel at optonline.net  Mon Oct 30 18:40:55 2006
From: ajsiegel at optonline.net (Arthur)
Date: Mon, 30 Oct 2006 12:40:55 -0500
Subject: [Edu-sig] Truth values and comparisons
In-Reply-To: <200610301107.04522.john.zelle@wartburg.edu>
References: <4545FE1A.2060303@optonline.com>
	<6B0E2998-010E-1000-CE84-18BA582E8EB6-Webmail-10011@mac.com>
	<45462CFE.2010100@optonline.com>
	<200610301107.04522.john.zelle@wartburg.edu>
Message-ID: <45463927.5000106@optonline.com>

John Zelle wrote:

>On Monday 30 October 2006 10:49 am, Arthur wrote:
>  
>
>>
>>thanks, but having some trouble:
>> >>> import Numeric as N
>> >>> a=N.array([0,0,0])
>> >>> b=N.array([0,0,1])
>> >>> a and b
>>
>>array([0, 0, 0])
>>    
>>
>
>This tells me that a zero array is being treated as False (the logical 
>extension to arrays of 0 being false. 
>  
>
>> >>> b and  a
>>
>>array([0, 0, 0])
>>    
>>
> 
>Right. In both cases, the answer is False, which Python gives to you by 
>handing you the first False expression. 
>
Ah. that is what I was missing, returns the first *False* expression.  I 
was interpreting Dave
to say that it returns the first expression, period.

With that, things fall into place.

Thanks,

Art


From ajsiegel at optonline.net  Mon Oct 30 19:15:50 2006
From: ajsiegel at optonline.net (Arthur)
Date: Mon, 30 Oct 2006 13:15:50 -0500
Subject: [Edu-sig] Truth values and comparisons
In-Reply-To: <200610301107.04522.john.zelle@wartburg.edu>
References: <4545FE1A.2060303@optonline.com>
	<6B0E2998-010E-1000-CE84-18BA582E8EB6-Webmail-10011@mac.com>
	<45462CFE.2010100@optonline.com>
	<200610301107.04522.john.zelle@wartburg.edu>
Message-ID: <45464156.3050805@optonline.com>

John Zelle wrote:

>This is why in teaching I prefer to use explicit tests:
>
>if x != 0:
>    do something
>
>Rather than 
>
>if x:
>    do something
>
>  
>
Yeah, so in the case I am looking at there is a branching based on 
whether either of 2 arrays are all zeros. 

So to achieve numpy compatibility, and to make the code more 
understandable to folks (like myself) who have some trouble in switching 
gears between numbers being used as numbers and at the same time being 
used for their truth values (kind of a trick really), I might do

if sum(x) !=0:
   use this array
else:
   use other array.

kind of thing.

The case here being distinguishable, in my mind, from the situation 
where one purposefully fills an array with 0's and 1's, with the 
intention of representing truth values. In *that* case the

if sum(x) !=0

would work just as well, but now would seem to be the trick solution 
rather than the elegant one.

Interesting how context matters in these kind of styling questions.

Assuming I am making sense...

Is concerning myself with this distinction sound programming, or is the 
hard core answer more to the effect what works works, what doesn't 
doesn't - and one should focus only on that, and perhaps the performance 
impact of available alternatives?

Though I guess we are all allowed to define "sound programming" for 
ourselves.

Art




Art

>--John
>
>  
>



From dcrosta at sccs.swarthmore.edu  Mon Oct 30 19:51:16 2006
From: dcrosta at sccs.swarthmore.edu (Dan Crosta)
Date: Mon, 30 Oct 2006 13:51:16 -0500
Subject: [Edu-sig] Truth values and comparisons
In-Reply-To: <45464156.3050805@optonline.com>
References: <4545FE1A.2060303@optonline.com>	<6B0E2998-010E-1000-CE84-18BA582E8EB6-Webmail-10011@mac.com>	<45462CFE.2010100@optonline.com>	<200610301107.04522.john.zelle@wartburg.edu>
	<45464156.3050805@optonline.com>
Message-ID: <454649A4.4080301@sccs.swarthmore.edu>

Arthur wrote:
> if sum(x) !=0:
>    use this array
> else:
>    use other array.

be careful:

 >>> a = [1, 0, -1]
 >>> if a: print "true"
true
 >>> if sum(a) != 0: print "true"


that's why it's probably safer and more readable to use any() and all(), which i 
believe were both introduced to __builtin__ in py2.5.

- d

From ajsiegel at optonline.net  Mon Oct 30 20:15:31 2006
From: ajsiegel at optonline.net (Arthur)
Date: Mon, 30 Oct 2006 14:15:31 -0500
Subject: [Edu-sig] Truth values and comparisons
In-Reply-To: <454649A4.4080301@sccs.swarthmore.edu>
References: <4545FE1A.2060303@optonline.com>
	<6B0E2998-010E-1000-CE84-18BA582E8EB6-Webmail-10011@mac.com>
	<45462CFE.2010100@optonline.com>
	<200610301107.04522.john.zelle@wartburg.edu>
	<45464156.3050805@optonline.com> <454649A4.4080301@sccs.swarthmore.edu>
Message-ID: <45464F53.1030100@optonline.com>

Dan Crosta wrote:

>
>be careful:
>
> >>> a = [1, 0, -1]
> >>> if a: print "true"
>true
> >>> if sum(a) != 0: print "true
>  
>
Oops. 

Definitely keep me away from space shuttle projects ;)

Art