pygame - importing GL - very bad...

[Mike C. Fletcher]

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 
>>> type
>>> that in front of all the opengl commands...
>>>
>>> So this solution is not something I like too... But I can see some 
>>> other
>>> 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 
like this:

from OpenGL import gl, glu, glut

gl.Rotate(...)
gl.Clear(gl.COLOR_BUFFER_BIT)

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

gl.rotate(...)
gl.clear(gl.COLOR_BUFFER_BIT)

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.

HTH,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com