pygame - importing GL - very bad...

[someone]

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.