关于python模块循环导入(circular imports)/相对导入(Relative Imports)/绝对导入(Absolute Imports)的官方资料

In general, don’t usefrom modulename import*.Doing so clutters the importer’s namespace. Some peopleavoid this idiom even with the few modules that were designed to be imported in this manner. Modules designed inthis manner includeTkinter,and threading.

Import modules at the top of a file. Doing so makes it clear what other modules your code requires and avoids questionsof whether the module name is in scope. Using one import per line makes it easy to add and delete module imports,but using multiple imports per line uses less screen space.

It’s good practice if you import modules in the following order:

1. standard library modules – e.g.sys, os, getopt, re

2. third-party library modules (anything installed in Python’s site-packages directory) – e.g. mx.DateTime, ZODB,PIL.Image, etc.

3. locally-developed modules

Never use relative package imports.If you’re writing code that’s in thepackage.sub.m1module and want toimportpackage.sub.m2,do not just writeimport m2,even though it’s legal. Write from package.sub import m2 instead.Relative imports can lead to a module being initialized twice, leading to confusing bugs. SeePEP 328 for details.

It is sometimes necessary to move imports to a function or class to avoid problems with circular imports. GordonMcMillan says:

Circular imports are fine where both modules use the “import <module>” form of import. They fail whenthe 2nd module wants to grab a name out of the first (“from module import name”) and the import is at thetop level. That’s because names in the 1st are not yet available, because the first module is busy importingthe 2nd.

In this case, if the second module is only used in one function, then the import can easily be moved into that function.By the time the import is called, the first module will have finished initializing, and the second module can do itsimport.

It may also be necessary to move imports out of the top level of code if some of the modules are platform-specific.In that case, it may not even be possible to import all of the modules at the top of the file. In this case, importing thecorrect modules in the corresponding platform-specific code is a good option.

Only move imports into a local scope, such as inside a function definition, if it’s necessary to solve a problem suchas avoiding a circular import or are trying to reduce the initialization time of a module. This technique is especiallyhelpful if many of the imports are unnecessary depending on how the program executes. You may also want to moveimports into a function if the modules are only ever used in that function. Note that loading a module the first time maybe expensive because of the one time initialization of the module, but loading a module multiple times is virtually free,costing only a couple of dictionary lookups. Even if the module name has gone out of scope, the module is probablyavailable in sys.modules.

If only instances of a specific class use a module, then it is reasonable to import the module in the class’s__init__method and then assign the module to an instance variable so that the module is always available (via that instancevariable) during the life of the object. Note that to delay an import until the class is instantiated, the import must beinside a method. Putting the import inside the class but outside of any method still causes the import to occur whenthe module is initialized.