pygame - importing GL - very bad...

Michael Torrie torriem at gmail.com
Wed Jan 2 22:57:02 CET 2013


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

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



More information about the Python-list mailing list