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@gmail.com> wrote:
On Sun, Jan 13, 2013 at 12:14 PM, Bruce Sherwood
<Bruce_Sherwood@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