pygame - importing GL - very bad...

[Andrew Berg]

On 2013.01.02 15:57, Michael Torrie wrote:
> 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.
This.

I have some code that imports multiprocessing.connection and I do
actually type out multiprocessing.connection.Client and it doesn't
bother me one bit. Code is read a lot more than it is written, even if
only one person ever sees it. The whole "less typing" thing is absurd,
especially when IDEs have completion features and stdlib modules share
similar or exact function names (is it subprocess.Popen or os.popen? I
guess the author wanted to save 2 seconds typing while anyone who reads
it has to spend 5-10 to find out which is being used) . I've been using
full namespaces since I started learning Python, and I even do it at the
interactive interpreter because it's just a habit. IMO, "from foo import
*" should only ever be used for /intentional/ namespace pollution (and
even then, there are probably better ways to do it).
-- 
CPython 3.3.0 | Windows NT 6.2.9200.16461