[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] pygame / ctypes
Peter Shinners wrote:
On Fri, 2006-01-20 at 11:09 +0800, Simon Wittber wrote:
It now appears that the ctypes module is to be included in the python
* Perhaps the ctype bindings would target different libraries onThis is where it's easier for PyOpenGL. We already have an
almost-certainly-deployed mostly-common library everywhere. We only
have to write 30 or 40 lines of code (mostly identical, just tweaks here
and there) to get a new platform supported. Having to write a thick
wrapper for each platform is a significant task. If you're not writing
directly to pre-existing metal, however, you wind up needing to install
the SDL binaries anyway.
different platforms? Using something windows-native on windows would
make distribution far simpler. Same for windows and osx using
alternative backends but sharing a common api.
Incidentally, OpenGL-ctypes isn't currently pure Python, we have 2
C-coded functions, and will likely have a few more as time goes on. My
goal (among others) here is to make the build system far simpler and
more robust than the SWIG one, not to entirely eliminate C compilation.
(That said, will likely eventually provide pure-Python backups as well).
* Allow "dynload" style bindings with ctype? I'm not sure if this isctypes is entirely dynamically loaded. In fact, it's dynamic at the
level where you can just go ahead, try to load the library, try to load
the function, and if something fails, just record a NULL object with
that name (I do this with the FreeGLUT GLUT extensions, for instance).
Client code can check for whether the function is non-NULL (or catch an
explicit error if they try to call it)... lets you drop basically all
ifdef-type operations. All the actual checking and NULL-ification can
be done in the common functions, so *every* function in the system can
be checked the same way. That said, I don't think I've actually gone
through and made the libraries themselves optional in OpenGL-ctypes, but
that's just a matter of returning a NULL module.
allowed, but it would allow distributing support for many binary
dependencies, but only cleanly only using what is available at runtime.
This may make Pygame more of an "API" target that any independent
package can support, and any game project can rely on.
AFAIK all that's happened is that Thomas has decided to propose ctypes'
inclusion again. I don't *think* we've heard anything from Guido that
it *has* been included. The question of whether the GCC-XML
auto-generation code would be included hasn't even been addressed AFAIK.
Mike C. Fletcher
Designer, VR Plumber, Coder