On Sun, 2004-12-26 at 15:43 -0800, Kirby Urner wrote: > > As to wxPython, I'm afraid it just failed a test of some importance to > > me. VPython does not run interactively from PyShell or PyCrust. It > > just hangs. It does run interactively from the native prompt and from > > the Idle prompt. > > > > Hence my cc to the wxpython dev list, mentioning VPython, and the "would be > nice" prospect of integrating it more effectively.
But I think you are talking about something more ambitious than the issue that is my immediate concern. Simply running VPython as one would anything else from the prompt does not imply any real level of integration. On the contrary, it seems that the shell and VPython need to successfully get out of each others' way. And the problem is they don't. Subprocesses, threads, or something. Anything that moves toward real integration would I suspect need to have most of its work done from the VPython side. Apparently VPython is quirky, greedy as it is - since it gives a lot of things that don't normally have trouble, trouble. PythonWin I think is another example. Closing a VPython window closes the IDE with it. Idle went to some lengths to accommodate VPython and prevent this. But it complicated the Idle architecture considerably. As a response to John's concerns I tried to look at the code that runs a script from Idle - and you have threads talking to subprocesses talking to sockets. Totally out of my league to try to truly follow, which is a kind of a shame. I wonder what, if anything, could be done from the VPython side to make it friendlier, without it losing it's uniqueness. Understanding that part of that uniqueness is the fact that the display is just implicitly there. As you know, >>import visual >>visual.sphere() is sufficient to create not only a sphere() but an entire rendering context and display for itself. I am guessing that is accomplished in ways other programs needing to cooperate with VPython tend not to like. I am at a loss to chip in to finding a solution. But a weekend spent trying to get deeper into boost::python and GTK indicates some real interest in the problem, and at least good intentions ;) Art _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
