Do I need to import a module several times?

5

I have a class file and a file for the main program, in the two files I need Pygame. I import the classes in the main program this way from classes import * . Do I need to import Pygame into the classes and into the main program, or is Pygame imported into the classes imported into the main program as well?

    
asked by anonymous 16.10.2017 / 12:41

2 answers

4

If you have in your class "classes.py" something like:

import pygame

class Classe1(...):
    ...

then the main file:

from classes import *

Both the defined classes and the "pygame" that were imported into the classes.py file are imported into the main file. The import command brings variables defined in the modules - it does not matter if the variables are created directly with the "=" sign, or they are references to the functions, and therefore created with the keyword "def", classes, created with the word "class" or imported from another "beyond" module with the "import" command. A variable that exists in the "class1" module can be imported from another module, and the "pygame" variable that refers to the pygame package is no exception.

What happens is that it is not considered good practice to use from XXX import * . This even breaks down the operation of various code analysis tools and various IDEs features.

You should import name by name of what you will use, which is defined in your "classes1" file, and do not use the "*". The use of "*" should only be done even in exceptions that confirm the rule that it should not be used. : -)

That said, you can write in your main module:

from classes1 import class1, class2, class3, pygame

But it's not recommended - it's best if you import Pygame as pygame into the main module, and the classes you want from your module, without using the "*":

import pygame
from classes1 import class1, class2, class3

What's important to keep in mind here is that Python will not "double-click" the pygame module. At runtime, it will simply see that the pygame has already been imported into another module, and create a variable in the current module to point to the same imported pygame module in the "classes1" module. The pygame files are not read more than once from the disk, no files are compiled more than once, and no pygame functionality will be present in duplicate memory.

So, in short - yes - the correct one in Python is to import into each module everything the code of that module will use, without depending on it being available in another module that you will also import. But there's no performance impact with that, just clarity that makes it easier to maintain your code.

Pygame in particular has a situation that was made to use import * - the constants with the key and event codes of the mouse and joystick . They are available separately in module pygame.locals .

Then you can do in your class module:

from pygame.locals import *

And have available to use the codes such as K_ESCAPE , and etc ... and by importing only the classes by name in the main module, does not pollute your namespace with the hundreds of names of pygame.locals .

    
16.10.2017 / 22:02
3

The import is usually only valid for the file where it is made, so you need to import explicitly into everyone who will use that module.

Of course if you import a module into a file and then import everything what's in it in another part of the application, the main one as it calls the question, what was imported there is available for use . But note that this only works if you import all the symbols completely. So yes, if you do from classes import * you do not have to import again. Just do not do this.

The problem is that it does this way pollutes the names being used and starts playing against just what the module serves which is to segregate parts of the application and the libraries.

Importation is just a mechanism to make symbols available from other codes for the current code. You say what you want.

While technically possible to leverage import, you should not do this.

import * may even help you type less, but it causes difficulties in project organization.

    
16.10.2017 / 12:59