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

Bruce Sherwood Bruce_Sherwood at ncsu.edu
Mon Jan 14 03:58:52 CET 2013


Since this was copied to the Python-Dev list, I want to go on record as
stating firmly that there is no evidence whatsoever to substantiate claims
that there has ever been some kind of conflict between VPython and Python.

Since __future__ was also mentioned, I'll take the opportunity to say that
I've been very impressed by the way the Python community has handled the
difficult 2->3 transition. For example, it has been a big help to the
educational uses of VPython that we could tell students simply to start
with "from __future__ import division, print_function", put parens around
print arguments, and thereby make it irrelevant whether they used Python 2
or Python 3. Many thanks to the Python development community!

Bruce Sherwood


On Sun, Jan 13, 2013 at 6:41 PM, Mark Janssen <dreamingforward at gmail.com>wrote:

> On Sun, Jan 13, 2013 at 12:14 PM, Bruce Sherwood
> <Bruce_Sherwood at ncsu.edu> wrote:
> > 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".
>
> Well it was bit enough that the python community created a brand-new
> language construct called import __future__ -- something never
> considered before then and which actually changes the behavior of
> python unlike any other module.  And perhaps I've just felt it more
> because I was a big proponent of both 3-d graphics as a way to keep
> python a draw for beginning programmers and also a big fan of
> scientific simulation.  No one had anything near vpython back then.
> (But ultimately I need to stop mentioning this issue to this vpython
> list because it's really the Python group which need to get back in
> sync.)
>
> > 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.
>
> I need to analyze this more carefully before commenting further....
>
> mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130113/ce21e744/attachment.html>


More information about the Python-Dev mailing list