<div dir="ltr">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. <div>
<br></div><div>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!<div>
<br></div><div style>Bruce Sherwood</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jan 13, 2013 at 6:41 PM, Mark Janssen <span dir="ltr"><<a href="mailto:dreamingforward@gmail.com" target="_blank">dreamingforward@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sun, Jan 13, 2013 at 12:14 PM, Bruce Sherwood<br>
<<a href="mailto:Bruce_Sherwood@ncsu.edu">Bruce_Sherwood@ncsu.edu</a>> wrote:<br>
> For the record, I do not know of any evidence whatsoever for a supposed<br>
> "split" between the tiny VPython community and the huge Python community<br>
> concerning floating point variables. Nor do I see anything in Python that<br>
> needs to be "fixed".<br>
<br>
</div>Well it was bit enough that the python community created a brand-new<br>
language construct called import __future__ -- something never<br>
considered before then and which actually changes the behavior of<br>
python unlike any other module.  And perhaps I've just felt it more<br>
because I was a big proponent of both 3-d graphics as a way to keep<br>
python a draw for beginning programmers and also a big fan of<br>
scientific simulation.  No one had anything near vpython back then.<br>
(But ultimately I need to stop mentioning this issue to this vpython<br>
list because it's really the Python group which need to get back in<br>
sync.)<br>
<div class="im"><br>
> The new (currently experimental) version of VPython based on wxPython must,<br>
> in order to run in a Cocoa environment on the Mac, make the interact loop be<br>
> the primary thread, with the user's Python calculations at worst a secondary<br>
> thread, which is the opposite of the older VPython, where the<br>
> interval-driven rendering thread was secondary to the user's calculations.<br>
> By the unusual stratagem of having VPython import the user's program it has<br>
> been possible to make this work, and at the same time greatly simplify the<br>
> C++ component of VPython by eliminating threading, with additional important<br>
> simplification from eliminating essentially all platform-dependent code<br>
> thanks to the multiplatform character of wxPython. The result is that nearly<br>
> all existing VPython programs will work without change, at the very small<br>
> cost of a few marginal cases requiring minor tweaking. I should alter the<br>
> documentation to make this important property of the new version more<br>
> salient.<br>
<br>
</div>I need to analyze this more carefully before commenting further....<br>
<span class="HOEnZb"><font color="#888888"><br>
mark<br>
</font></span></blockquote></div><br></div>