Re: [Python-Dev] [Visualpython-users] How VPython 6 differs from VPython 5
On Sun, Jan 13, 2013 at 1:15 AM, Bruce Sherwood <Bruce_Sherwood@ncsu.edu> wrote:
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.
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.)
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.
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
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 12:14 PM, Bruce Sherwood <Bruce_Sherwood@ncsu.edu> wrote:
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.)
I need to analyze this more carefully before commenting further.... mark
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:
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 12:14 PM, Bruce Sherwood <Bruce_Sherwood@ncsu.edu> wrote:
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.)
I need to analyze this more carefully before commenting further.... mark
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:
participants (3)
-
Antoine Pitrou -
Bruce Sherwood -
Mark Janssen