pygame - importing GL - very bad...
someone
newsboost at gmail.com
Wed Jan 2 20:53:03 EST 2013
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.
More information about the Python-list
mailing list