pygame - importing GL - very bad...
Mike C. Fletcher
mcfletch at vrplumber.com
Thu Jan 3 15:09:14 CET 2013
On 13-01-02 08:53 PM, someone wrote:
> On 01/02/2013 10:57 PM, Michael Torrie wrote:
>> On 01/01/2013 04:49 PM, someone wrote:
>>> On 01/01/2013 12:13 PM, Chris Angelico wrote:
>>> > You could simply
>>> > import OpenGL.GL as GL
>>> You're right - but I forgot to write that even though this maybe
>>> should/is recommended many places then I've seen a lot of opengl
>>> code on
>>> the internet and IMHO NOBODY does that and it'll be a lot slower to
>>> that in front of all the opengl commands...
>>> So this solution is not something I like too... But I can see some
>>> people came up with good solutions, which I didn't knew about..
>> Why is this solution not to your liking? Python has namespaces for a
> Because the amount of opengl-functions is HUGE, many people (at least
> on the internet) do as I and (IMHO) it takes up too much time to
> change a lot of code plus sometimes I grab/modify small code pieces
> from the internet and it makes my development SO MUCH faster just to
> make an exception here with star-import for opengl-commands.
I'd agree on it being rather impractical/pointless/verbose to have every
single OpenGL entry point and constant have an extra gl. or glu. or
glut. added to the front. OpenGL/GLU/GLUT is already namespaced, but
using C-style prefix namespacing (that is gl* glu* glut* and GL_*,
GLU_*, GLUT_*), so adding Python style namespacing to the front of that
makes it very verbose. OpenGL-using code is *littered* with OpenGL
entry points and constants (and yes, I intend the slight slight), so
that's going to make it rather annoying to work with.
PyOpenGL's current approach is mostly attempting to maintain backward
compatibility with the older revisions. wxPython actually rewrote its
whole interface to go from * imports into namespaced lookups and then
wrote a little migration tool that would attempt to rewrite your code
for the new version. They also provided a transitional API so that code
could mix-and-match the styles. For PyOpenGL that would look something
from OpenGL import gl, glu, glut
or, if you really needed PEP-8 compliance, and don't mind making the API
look nothing like the original, we might even go to:
from opengl import gl, glu, glut
Either of which would *also* make it possible for us to lazy-load the
entry points and symbols (that would save quite a bit of ram).
But I'm not actually likely to do this, as it makes it far more annoying
to work with C-oriented references (and since PyOpenGL is primarily used
by new OpenGL coders who need to lean heavily on references, that's a
big deal). Currently you can often copy-and-paste C code into PyOpenGL
and have it work properly as far as the OpenGL part is concerned (arrays
and the like need to be rewritten, but that's not something I can
control, really). People are already confused by the small variations
from C OpenGL, making the API look entirely different wouldn't be a good
direction to move, IMO.
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Python-list