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