The Ultimate Guide To Python __all__

In this article, we will be discussing Python __all__ how it is used in Python programming.

The Python variable __all__ can be defined in a package’s __init__.py file. The list of strings in the __all__ variable determines the values which are imported whenever a program runs. Look at __all__ in further depth.

What do Certain Python Functions Have Double Underscores?

Given that Python has special methods, the name begins with _ and concludes with the same character. These techniques are offered by Python for usage as operator overloading based on the user. Python provides this practice as a way to distinguish between user-defined functions and module functions.

Let’s refer to the example:

MyClass.py

class SampleClass():
     def __summation__(self, a, b):
          print(a+b)

Python Interpreter

> import MyClass
> SCobj = MyClass.SampleClass()
> SCobj.__summation__(10,10)
20
> SCobj.__summation__(50023,2123)
52146

What is Python __all__?

Python __all__ is a collection of the module’s public objects as determined by import *. The default of concealing anything that starts with an underscore is overridden by the __all__.

If __all__ is present, objects that begin with an underline or are not named in it are not technically hidden; if you recognize their names, you may view and access them just like any other object. The contrast only matters in the instance of an “import *,” which is not advised in any case.

When the command from <module name> import * is run on a module, the list of strings in the __all__ list in Python specifies which symbols will be exported.

Why is Python __all__ Used?

The module’s semantically “public” names are revealed by the __all_ command. Users are required to utilize names that are present in __all__ and may anticipate that they won’t change.

Python exports all identifiers that do not begin with an underscore by default. In all likelihood, you could count on this process. Because it eliminates the need to mention the names twice, using the _  standard can be more appealing.

Let’s look at the following example:

The variables Python and Java are explicitly exported by the program below.

ModuleFile.py

__all__ = ['Python', 'Java']

Python = 2

def LangProgramming(): return 'Java'

Then, these variables may be imported into another file, such as the one below.

MyApp.py

from ModuleFile import *

print(Python)
print(Java())

Output

2
Java

Python __all__ in __init__.py

Python must have the __init__.py files in order for it to recognize the folders as having packages. __init__.py can be a blank file in the most basic scenario, but it can also run the package’s startup code or create the __all__ variable.

Most of the time, a package is composed of packages that may import each other but are always connected by a __init__.py file.

Lists vs Tuples within Modules Python __all__

Neither the usage of a list nor a tuple is required. Tuple, on the other hand, depicts a series of multiple kinds of objects, whereas list idiomatically denotes a succession of the same sort of items. This is also represented by type hints, which include positional fields inside of a tuple[str, int, int] but some list[str | int] fields.

However, note that PEP 8 standards declare __all__ being a list type.

How To Import Packages as __main__ Aliases Inside __init__.py?

Within the __init__.py folder, include the following:

import package1
import package2 as p2

Then, within the console run the following commands

from samplepackage import *
funcInst = package1.packageFunction()
classInst = p2.packageClass()

How to Properly Implement __all__ and __init__.py

The excellent feature of __all__ is that it directs import instructions without automatically importing modules. It is unnecessary to use both import * and __all__; just __all __ is required.

In my opinion, one of the most compelling arguments for using import * in a __init__ .py to import packages is the ability to restructure a script that has multiplied into several scripts without causing an application to fail. However, if you’re creating a package from scratch. I believe that empty __init__ .py files are the best option.

__all__ Behaving Differently on __init__ and Modules

When __all__ is present in a module, it chooses which objects are made accessible when the module import * command is executed.

Let’s take this package structure as example.

package
├── __init__.py
├── package_1.py
└── package_2.py

package_1.py

__all__ = ["foo"]
def foo(): pass
def bar(): pass

The availability of foo but not bar is determined by running from package.package_1 import *.

Furthermore, since foo() may be used to call it, there is no requirement to reference the package.

When __init__ consists of __all__,

The two implications of executing from package import * are as follows:

• All module scripts within __all__ will be executed (as they are imported).
• The namespace makes these modules accessible.

In other words, if __init__ is of the type:

__all__ = ["package_1", "package_2"]

The scripts for packages 1 and 2 will then be executed by executing from package import *, making both modules available. Therefore, package_1.foo() rather than package.package_1.foo() may now be used to invoke the method foo inside of package_1.

Alternatively, using from package.module_1 import foo could be preferable if that’s your goal. Given that it makes foo available as foo().

FAQs

Conclusion

In this article we’ve discussed Python __all__ how it helps in importing all the classes within a Python package. Python __all__ consists of a list of strings that contain the names of public packages and objects. The role of __all__ in __init__.py file and how it aids in recognizing the folders that contain importable packages.