5 Answers
5

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:

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.

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.

Performance. When you type smth like foo.bar.baz.ClassName.classmethod() there will be 4 lookups in namespaces, which cost some time. The more such lines in code, the more unnecessary waste of time.

Simplicity. When you write tutorials, you try to explain things as simple as it possible. So the less code, the better tutorial.

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.

Namespase pollution. When you imort everything from module into globals, you are more limited in the choice of global variables. For example, from struct import * and 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?).

Mess. When you use such imports many times, from foo import *; from bar import *; from baz import * some variables or constants may be shaded or overwritten. In this example foo.version is overwritten with bar.version (and 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. E.g.: