Can someone please explain this weird Pygame impor

Question

I see that people usually import Pygame like this:

import pygame
from pygame.locals import *

I don't understand what's the second line for. If we already imported the whole of Pygame, why import pygame.locals? Doesn't Pygame already include it once it's imported?

Answer 1

import pygame
from pygame.locals import *

http://www.pygame.org/docs/tut/ImportInit.html

The first line here is the only necessary one. It imports all the available pygame modules into the pygame package. The second line is optional, and puts a limited set of constants and functions into the global namespace of your script.

Answer 2

Actually, from the pygame docs:

This module contains various constants used by Pygame. It's contents are automatically placed in the pygame module namespace. However, an application can use pygame.locals to include only the Pygame constants with a 'from pygame.locals import *'.

So all these constants are already there when you use import pygame. We can see this if we do this:

>>> import pygame
>>> from pygame.locals import *
>>> set(dir(pygame.locals)).issubset(set(dir(pygame)))
True

So, pygame.locals is a subset of import pygame.. So absolutely no point doing it if you have already imported pygame! Apart from it allows you to access them without the pygame prefix.

Answer 3

import pygame

imports the pygame module into the "pygame" namespace.

from pygame.locals import *

copys all names in pygame.locals into your current namespace. This is not neccessary, but saves you typing.

Answer 4

I would not worry about it. I know you may have been told that * imports are bad. That is true to some extent, unless Pygame developers specifically defined the __all__ attribute, in which they've put all those handy-dandy constants in, and they have. So, that way they made this particular * import safe.

The * relates to the __all__ attribute, so search the pygame.locals source code for all the constants included in the __all__ attribute.

Answer 5

Doesn't Pygame already include it once it's imported?

Nope. Not necessarily.

stefanos-imac:python borini$ touch a/__init__.py
stefanos-imac:python borini$ touch a/b.py
stefanos-imac:python borini$ echo "print 'hello' " >a/b.py 
stefanos-imac:python borini$ python
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import a
>>> import a.b
hello
>>> 

Answer 6

When you execute

import pygame

the pygame is fully imported and ready to work, no more imports are needed.

Now the question is about this line:

from pygame.locals import *

There are several reasons why this should be used, and a few reasons not to do so.

1. Performance. When you type something like foo.bar.baz.ClassName.classmethod(), there will be 4 lookups in the namespace, which cost some time. The more such lines in code, the more unnecessary waste of time.
2. Simplicity. When you write tutorials, you try to explain things as simple as it possible. So the less code, the better tutorial.
3. Ease. When you type your code, you spread it to different files. Because it is easier to work with smaller side-files, and then import all of them in the main. But you completely understand what you are importing.
4. Namespase pollution. When you import everything from module into globals, you are more limited in the choice of global variables. For example, from struct import * you can't name your function as pack. So, before use such imports, you should explore the module. What does it contain? What does it import by itself?
5. Mess. When you use such imports many times, from foo import * and from bar import * and from baz import *, some variables or constants may be shaded or overwritten. In this example, foo.version is overwritten with bar.version, now named as version. So, foo.checkversion() will not work correctly anymore.

The proper way is to import the commonly used functions in explicit form, or make them a quick reference, especially when you do not know the module well.

For example:

from foo.bar.baz import a_very_useful_function

or

import foo.bar.baz
quick_referenced_fn = foo.bar.baz.a_very_useful_function

Here quick_referenced_fn is still foo.bar.baz.a_very_useful_function and works in the namespace of foo.bar.baz, but interpreter knows its address directly and will not make additional lookups.