[Python-Dev] [Visualpython-users] How VPython 6 differs from VPython 5

[Bruce Sherwood]

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 at gmail.com>wrote:

> On Sun, Jan 13, 2013 at 1:15 AM, Bruce Sherwood <Bruce_Sherwood at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130113/dbb585fa/attachment-0001.html>