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
--
http://mail.python.org/mailman/listinfo/python-list
