For the record, I do not know of any evidence whatsoever for a supposed "split" between the tiny VPython community and the huge Python community concerning floating point variables. Nor do I see anything in Python that needs to be "fixed".

The new (currently experimental) version of VPython based on wxPython must, in order to run in a Cocoa environment on the Mac, make the interact loop be the primary thread, with the user's Python calculations at worst a secondary thread, which is the opposite of the older VPython, where the interval-driven rendering thread was secondary to the user's calculations. By the unusual stratagem of having VPython import the user's program it has been possible to make this work, and at the same time greatly simplify the C++ component of VPython by eliminating threading, with additional important simplification from eliminating essentially all platform-dependent code thanks to the multiplatform character of wxPython. The result is that nearly all existing VPython programs will work without change, at the very small cost of a few marginal cases requiring minor tweaking. I should alter the documentation to make this important property of the new version more salient.

Minor point: The meaning of the new VPython "sleep" is precisely to relinquish control to the OS, including the GUI. During sleep one wants the wxPython window controls to remain active, which will not be the case with time.sleep, which knows nothing about the wxPython interact loop. So I think the meaning of "sleep" is the usual meaning.

Bruce Sherwood


On Sun, Jan 13, 2013 at 9:13 AM, Mark Janssen <dreamingforward@gmail.com> wrote:
On Sun, Jan 13, 2013 at 1:15 AM, Bruce Sherwood <Bruce_Sherwood@ncsu.edu> wrote:
> Here is detailed information on how VPython 6 differs from VPython 5, which
> will be incorporated in the Help for upcoming releases of VPython 6. Note
> that the fact that in a main program __name__ isn't '__main__' is an
> unavoidable "feature", not a bug. That is, there doesn't seem to be a way to
> make this work.

Hi, Bruce.  I think there are two ways of fixing this.  One is to get
down to the C language level, and share the C main() loop, which will
percolate back up into the CPython loop.  The other involves mending
the split that I've been mentioning that happened over floating point
between the VPython developers and the Python-dev group.  Then perhaps
Guido will accept VPython using/sharing the __main__ "loop".  (I'm
CC'ing him in this message.)  So, either of these tracks should fix
this problem.  This is why I keep mentioning the important of healing
that split between the parties arguing in the two camps.  Perhaps Tim
Peters will be able help bridge this gap.

> Changes from VPython 5
>
> The new version makes an essential change to the syntax of VPython programs.
> Now, an animation loop MUST contain a rate or sleep statement, which limits
> the number of loop iterations per second as before but also when appropriate
> (about 30 times per second) updates the 3D scene and handles mouse and
> keyboard events. Without a rate or sleep statement, the scene will not be
> updated until and unless the loop is completed.

I think this is perfectly acceptible and is just a necessary
restriction wherefrom the OS *must* maintain ultimate control of I/O.
Python sits in userspace surrounded by the larger computation
environment, so this is only fair that an OS call is made so that it
can keep things in "check".   Naming it "sleep" is okay, but makes it
sound more like a  voluntary thing, and as you probably know, is the
traditional name for relinquishng some control to the OS.  (cf. Unix
Systems Programming, Robbins, et al.)

> You should use the new function sleep rather than time.sleep. The new
> function periodically renders the scene and processes mouse events, making
> it possible to continue using zoom and rotate, whereas time.sleep does not
> do this.

This is strange to me.  I think this is where VPython must be ahead of
the curve and not close enough to the Linux development communities.

> For technical reasons, it is necessary for VPython 6 to do something rather
> unusual. When you import visual (or vis), your own program is in turn
> imported by the visual module.

Again this is because of the faction that was created by in 200?,
regarding the Vpython community vs. the python-dev.  Really, this
should be mended.

Anyway, I hope that any of this made sense.

Thanks for your help!

Mark