pygame - importing GL - very bad...

[someone]

On 01/03/2013 03:09 PM, Mike C. Fletcher wrote:
> On 13-01-02 08:53 PM, someone wrote:

>>>> 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

Good to hear, I'm not alone, thanks.

> 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)

Ok, that's interesting. However, I like it the way it is, where I can 
copy/paste C-code from the web and change some small things and it'll 
work and fit into my needs. BUT I didn't know there was such a 
transitional API - interesting. I however don't want to be a first-mover 
- let's see if sufficiently many people will use this and then I'll 
consider doing it too. At the moment, I still think the star-import is 
good because it makes it easy to look for C-code and program it (=do it) 
like people would do it in C.

> 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)

Erhm, that's the same as above. Is that what you meant to write?

> 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

Agree - that's something I like.

> from C OpenGL, making the API look entirely different wouldn't be a good
> direction to move, IMO.

Well, I'm sometimes a bit annoyed that python doesn't give as many 
warnings/errors as one gets in C - for instance sometimes I copy/paste 
and forget to remove the trailing semi-colons. However after I began to 
use pylint and friends, this error will be caught. Then sometimes I 
forgot to add () for function calls, which in C would cause an error by 
the compiler but which python allows so one can get the object (which 
maybe is also a good reason, but at least in the beginning when I 
learned python, this was very annoying + confusing to me).

Thanks for the comments about this transitional opengl-stuff - I was 
unaware of that. Currently it's not so interesting to me, I like it the 
way I do it now so I can quickly grab code pieces from C/C++ from the 
web and change it to suit my needs...