[Edu-sig] The fate of vpython

[Arthur Siegel]

On Mon, 2006-10-09 at 10:54 -0700, Dethe Elza wrote:
> I agree with John, and will make a stronger statement that C++ and  
> Boost are part of the problem, not part of the solution as far as  
> future development of VPython goes.  

But...and about the only but I can think of...

One of the beauties of the current distro is that one can inherit the
exposed C++ classes - i.e. one can inherit and extend cvisual.sphere in
a Python class.  Hate to see that go away, in large part because of its
pedagogical value. And impression is that this feature would be
difficult to preserve with another extension mechanism.  But its mostly
an impression.

> Jonathan Brandemeyer, the most recent  
> maintainer of VPython, said that he did make some attempts to use  
> PyOpenGL but found it to be too slow for VPython.  That's why I think  
> Pyrex might be the way to go

> --it looks mostly like Python code, but  
> lets you call C code inline to make more optomized calls into the  
> OpenGL infrastructure.
> 

You may be right.  Recently came across a major 3d game engine which had
forked in the direction of a pyrex solution.

> My other hope for VPython would be to build it on a more capable 3D  
> system, such as Ogre or Panda3D (Mike Fletcher keeps a large list of  
> such systems: http://www.vrplumber.com/py3d.py).  In this scenario,  
> VPython would be an easier entry point into one of these more capable  
> (and correspondingly more complex) systems, an Ogre-lite so to  
> speak.  

Here I finally get to strongly disagree.  Vpython IMO should remain
stand-alone, light-weight.  Please, please.

I also see it as a possible entry point to things like Ogre and Panda3d,
but that is on a cognitive level, not a technical level. 

As a component to something either high-level and more heavyweight, or
more low-level, I don't see a purpose to it. I doubt it does anything
that Panda3d can't already do, and certainly nothing OpenGL can't
already do.

Vpython should be a lesson in how much one can do with not that much.
Let folks outgrow it, before they move on to other tools. Not many will.

Otherwise cognitive overload.

Again I think of VPython as in fact the perfect visual extension to
Python - something (with effort) you can keep in your head at one time. 

Its that sweet spot in the middle that makes it right for students, and
string-theorists ;).

Art


> This would create a new dependency on an external library,  
> which is bad, but may give VPython better evolutionary legs, which  
> would be good.  My measure of how likely this scenario is, is based  
> on having one of the scenegraph tools Just Work for the three main  
> platforms (Windows, Linux, OS X), and that hasn't happened yet.



> There is so much of interest going on in the 3D world right now, with  
> good working systems finally available for X3D[1], open-source tools  
> to build 3D avatars for Second Life[2], machinima systems[3], and  
> tools like Google SketchUp[4] making 3D accessible to anyone who is  
> interested.  It is sad to see VPython atrophy right now, but I'm sure  
> that the ideas in it will find a home somewhere, whether the code  
> does or not.
> 
> [1] http://www.web3d.org/
> [2] http://www.avimator.com/
> [3] http://orange.blender.org/
> 
> --Dethe
> 
> On 9-Oct-06, at 10:16 AM, Arthur Siegel wrote:
> 
> > On Mon, 2006-10-09 at 11:48 -0500, John Zelle wrote:
> >> I am also very concerned about this situation, as I think VPython  
> >> is a
> >> wonderful tool (to which I've contributed).
> >
> > Hi John -
> >
> > Thanks for that concern.
> >
> > If you are following the vpython list you see that I am digging  
> > into the
> > immediate issues.  I have no C++ skills to have atrophied, but - as I
> > said there  - getting an understanding of building Python  
> > extensions has
> > been on my agenda and something concrete to dig into helps, so that  
> > I am
> > having some fun with it.
> >
> > But I agree that for all the simplicity on the surface, there is more
> > complexity underneath than one would hope for. It had Dethe, for
> > example, throwing up his hands in trying a port to native Mac.
> >
> > The project funding is over, so that only volunteer resources are
> > available to salvage it.
> >
> > I agree with you that more radical strategy than following the current
> > path is probably necessary.
> >
> > Py-OpenGL is itself moving to a ctypes implementation, and ctypes  
> > is now
> > in the core Python distribution.
> >
> > Slight problem being that I have no understanding of what that means.
> > Intuition is that the best solution might be there, someplace.
> >
> > Meantime I am getting more familiar with the current C++ code, so  
> > that I
> > should be in a position to contribute to a re-implementation, given a
> > strategy to do so.
> >
> > But it is OTOH scary that as to the vpython list, I seem to be the  
> > guru
> > at the moment, since I certainly don't consider myself qualified to
> > think this through without folks with more low-level skills.
> >
> > I am holding off to going the scipy list with things until I at least
> > can talk with some measure of intelligence - but I am still thinking
> > that is where the best hope might be.
> >
> > Art
> >
> >
> >
> > _______________________________________________
> > Edu-sig mailing list
> > Edu-sig at python.org
> > http://mail.python.org/mailman/listinfo/edu-sig
> 
> 
> There are two ways of constructing a software design.  One way is to  
> make it so simple there are obviously no deficiencies and the other  
> way is to make it so complicated that there are no obvious  
> deficiencies.  --C.A.R. Hoare
> 
>