then you will end up importing$_{pkg.mod}$ . If you execute$_{from ..subpkg2 import mod}$ from within$_{pkg.}$ subpkg1 you will import pkg.subpkg2.mod . The specification for relative imports is contained in the Package Relative Imports section. importlib.import_module() is provided to support applications that determine dynamically the modules to be loaded. Raises an auditing event import with arguments module , filename , sys.path , sys.meta_path , sys. path_hooks . A future statement is a directive to the compiler that a particular module should be compiled using syntax or semantics that will be available in a specified future release of Python where the feature becomes standard. The future statement is intended to ease migration to future versions of Python that introduce incompatible changes to the language. It allows use of the new features on a per-module basis before the release in which the feature becomes standard. A future statement must appear near the top of the module. The only lines that can appear before a future statement are: The only feature that requires using the future statement is$_{annotations}$(see PEP 563 ). All historical features enabled by the future statement are still recognized by Python 3. The list in- cludes absolute_import , $_{division}$, $_{generators}$, generator_stop , unicode_literals , print_function ,$_{nested_scopes}$and$_{with_statement}$ . They are all redundant because they are al- ways enabled, and only kept for backwards compatibility. A future statement is recognized and treated specially at compile time: Changes to the semantics of core constructs are often implemented by generating different code. It may even be the case that a new feature introduces new incom- patible syntax (such as a new reserved word), in which case the compiler may need to parse the module differently. Such decisions cannot be pushed off until runtime. For any given release, the compiler knows which feature names have been defined, and raises a compile-time error if a future statement contains a feature not known to it. The direct runtime semantics are the same as for any import statement: there is a standard module$_{__future__}$ , described later, and it will be imported in the usual way at the time the future statement is executed. The interesting runtime semantics depend on the specific feature enabled by the future statement. Note that there is nothing special about the statement: import __future__ [ as name] That is not a future statement; it’s an ordinary import statement with no special semantics or syntax restrictions. Code compiled by calls to the built-in functions$_{exec()}$ and$_{compile()}$ that occur in a module$_{M}$ containing a future statement will, by default, use the new syntax or semantics associated with the future statement. This can be Chapter 7. Simple statements 92 • other future statements. • blank lines, and • comments, • the module docstring (if any), 7.11.1 Future statements The Python Language Reference, Release 3.9.5 $_{future_stmt}$::= "from" "__future__" "import" feature ["as" identifier ] ("," feature ["as" identifier ])* | "from" "__future__" "import" "(" feature ["as" identifier ] ("," feature ["as" identifier ])* [","] ")" feature ::= identifier