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.
reason. They both keep code separated and modular. Use them. At most
you should import the most commonly-used symbols only, and refer to the
rest through their respective namespaces (with whatever alias you've
given the import). There is no additional typing burden.
There are SO MANY "common-only used" symbols, but I also once believed
that I should do as you write (which I agree with you, is the correct
way to do it). I'm not saying you're incorrect - I just say that it
speeds up my development significantly to only use star-import for
opengl-stuff.
Despite your opinion, it is completely false that "NOBODY does [this]."
In other words a decent python programmer rarely does "from blah import
*." There's a reason why pylint flags this. Frankly the code you've
seen on the internet that does this is not setting a good example. It's
bad programming practice, plain and simple. I'm a bit surprised that
others on this list in this thread intimated that it's okay to do import
*. The only place where I've seen an import * that actually belonged
Generally you're completely correct. After having worked with opengl for
some time however, I must say that my personal opinion is that the
benefits of making an exception here outweights the disadvantages a lot
- but only for the many MANY opengl-commands.
was in an __init__.py that brought sub-module symbols into the main
package namespace, and even then I figure there's got to be a better way.
Maybe this is your own private pet project, but if you ever plan to
involve others in your development, leaving the OpenGL symbols in their
own namespaces will make code maintenance a lot easier down the line.
As said, you're completely correct. Until now it's my own private
project, though I'm considering making it open-source after some time.
Right now I just need to develop as quick as possible because I have a
lot of work to do.
Later on another developer may come along and if it's not easy to tell
at a glance if a symbol is provided by another module or if it's
something you defined, he's going to have a lot of unnecessary work.
Don't worry about that - opengl programmers immediately see and
recognize opengl-commands... This, I deem is absolutely not a problem -
opengl programmers easily recognize opengl commands immediately. They
also usually begin with GL_.... - hence it's quite easy to see what is
an opengl command and everything that isn't an opengl-command is (as you
suggest) NOT imported using "star"-import.
--
http://mail.python.org/mailman/listinfo/python-list
