Brian asked me to explain what benefits I'm expecting from a ctypes version of OpenGL versus the PyOpenGLSWIG version. So, why not post it where everyone can read it (if one person asks, probably 10 want to know)...

   * Easier compilation/more robust operation
         o Probably 90% of our time in PyOpenGLSWIG is spent on
           compilation issues
               + What few pieces of C code we'll need are going to be
                 simple and straightforward, easily debugged and then
                 forgotten, effectively we have a few pieces of code to
                 do those things that are either a serious pain in
                 ctypes or need C-level speed to be practical... and we
                 only decide which pieces those are with real-world
                 data saying "yes, that's the problem"
         o We piggy-back on ctypes/libffi porting, let them deal with the 
           bulk of the cross-platform issues and the complex compilation 
           issues and we just need to be able to find the OpenGL DLLs and 
           pull entry points out of them.
   * Lower barrier to entry for users to hack on the system and become
     developers
         o Instead of an expanding macro system (SWIG) that matches via
           unseen rules and can only be debugged by spelunking through
           the final generated code, we get a system where you get a
           traceback showing exactly what we were trying to do
               + Extension modules will just import the services they
                 need and use them, they won't have macro
                 comments that interact with a funky-hacked distutils
                 script to decide which versions to build
         o Make it possible to hack on new (extension) modules for the
           system without requiring a long compile-test cycle (which
           kills my productivity when developing new modules)
         o Reduce the number of languages a user needs to know to
           develop PyOpenGL
               + Comes right down to it, I have so little time to work
                 on PyOpenGL that I really need to get to the point
                 where other people can do the work.  Everyone who
                 wants to use PyOpenGL knows Python, only a fraction
                 know C...
   * Flexibility
         o Make it possible to hook into the wrapping aspects of the system
               + e.g. register a handler for a data-type (e.g. a PyGame
                 surface, or a PyMedia data-stream) such that it can be
                 efficiently handled as a texture/array data-type
         o Make it easily possible to include modules to which I don't
           have access (really this is more of a "lower barrier to
           entry" thing, but it means that people who have a 2.0 GL.h
           header can provide 2.0 features without needing them to be
           present on the machine compiling a binary distribution)
               + We can actually just try to find the entry point, and
                 if we don't, just catch the error... avoids lots of
                 "if opengl version > XXX" code
         o Ready for PyPy when it matures (i.e. move the code up into
           Python with as little C code as possible)
   * Cleaner design (hopefully)
         o Tarn's design was heavily influenced by SWIG's
           macro-expansion philosophy... it's a little hard for people
           to follow, even when they've been working on it as long as I
           have.  It's elegant in many ways, but it's also a pretty
           serious PITA for maintenance.  And in the end, I just don't
           *like* massively-nested macro-expansions!
         o Eliminate the complex and fragile compilation scripts; have
           2 or 3 extensions, something to kick off the Togl
           compilation (assuming we still distribute it (likely)) and a
           big block of Python packages that just get copied over
           unchanged.

And there you have it, a quick explanation of why it's at least worthwhile to try building OpenGL-ctypes IMO. Oh, apologies for the formatting, I didn't think to post this until after Thunderbird had converted it into plain-text, and I don't really have time to reformat it this afternoon.