<p>I see <code>__all__</code> in <code>__init__.py</code> files. What does it do?</p>

[{'answer_id': 44842, 'author': 'Jimmy', 'author_id': 4435, 'author_profile': 'https://Stackoverflow.com/users/4435', 'pm_score': 11, 'selected': True, 'text': "<p>It's a list of public objects of that module, as interpreted by <code>import *</code>. It overrides the default of hiding everything that begins with an underscore.</p>\n"}, {'answer_id': 64130, 'author': 'Alec Thomas', 'author_id': 7980, 'author_profile': 'https://Stackoverflow.com/users/7980', 'pm_score': 10, 'selected': False, 'text': '<p>Linked to, but not explicitly mentioned here, is exactly when <code>__all__</code> is used. It is a list of strings defining what symbols in a module will be exported when <code>from &lt;module&gt; import *</code> is used on the module.</p>\n\n<p>For example, the following code in a <code>foo.py</code> explicitly exports the symbols <code>bar</code> and <code>baz</code>:</p>\n\n<pre><code>__all__ = [\'bar\', \'baz\']\n\nwaz = 5\nbar = 10\ndef baz(): return \'baz\'\n</code></pre>\n\n<p>These symbols can then be imported like so:</p>\n\n<pre><code>from foo import *\n\nprint(bar)\nprint(baz)\n\n# The following will trigger an exception, as "waz" is not exported by the module\nprint(waz)\n</code></pre>\n\n<p>If the <code>__all__</code> above is commented out, this code will then execute to completion, as the default behaviour of <code>import *</code> is to import all symbols that do not begin with an underscore, from the given namespace.</p>\n\n<p>Reference: <a href="https://docs.python.org/tutorial/modules.html#importing-from-a-package" rel="noreferrer">https://docs.python.org/tutorial/modules.html#importing-from-a-package</a></p>\n\n<p><strong>NOTE:</strong> <code>__all__</code> affects the <code>from &lt;module&gt; import *</code> behavior only. Members that are not mentioned in <code>__all__</code> are still accessible from outside the module and can be imported with <code>from &lt;module&gt; import &lt;member&gt;</code>.</p>\n'}, {'answer_id': 2838800, 'author': 'L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳', 'author_id': 80243, 'author_profile': 'https://Stackoverflow.com/users/80243', 'pm_score': 7, 'selected': False, 'text': '<p>It also changes what pydoc will show:</p>\n\n<p>module1.py</p>\n\n<pre><code>a = "A"\nb = "B"\nc = "C"\n</code></pre>\n\n<p>module2.py</p>\n\n<pre><code>__all__ = [\'a\', \'b\']\n\na = "A"\nb = "B"\nc = "C"\n</code></pre>\n\n<p>$ pydoc module1</p>\n\n<pre>\nHelp on module module1:\n\n<b>NAME</b>\n    module1\n\n<b>FILE</b>\n    module1.py\n\n<b>DATA</b>\n    <b>a</b> = \'A\'\n    <b>b</b> = \'B\'\n    <b>c</b> = \'C\'\n</pre>\n\n<p>$ pydoc module2</p>\n\n<pre>\nHelp on module module2:\n\n<b>NAME</b>\n    module2\n\n<b>FILE</b>\n    module2.py\n\n<b>DATA</b>\n    <b>__all__</b> = [\'a\', \'b\']\n    <b>a</b> = \'A\'\n    <b>b</b> = \'B\'\n</pre>\n\n<p>I declare <code>__all__</code> in all my modules, as well as underscore internal details, these really help when using things you\'ve never used before in live interpreter sessions.</p>\n'}, {'answer_id': 16595377, 'author': 'MartinStettner', 'author_id': 81424, 'author_profile': 'https://Stackoverflow.com/users/81424', 'pm_score': 8, 'selected': False, 'text': '<p>I\'m just adding this to be precise:</p>\n\n<p>All other answers refer to <em>modules</em>. The original question explicitely mentioned <code>__all__</code> in <code>__init__.py</code> files, so this is about python <em>packages</em>.</p>\n\n<p>Generally, <code>__all__</code> only comes into play when the <code>from xxx import *</code> variant of the <code>import</code> statement is used. This applies to packages as well as to modules.</p>\n\n<p>The behaviour for modules is explained in the other answers. The exact behaviour for packages is described <a href="http://docs.python.org/2/tutorial/modules.html#importing-from-a-package">here</a> in detail.</p>\n\n<p>In short, <code>__all__</code> on package level does approximately the same thing as for modules, except it deals with <em>modules within the package</em>  (in contrast to specifying <em>names within the module</em>). So <code>__all__</code> specifies all modules that shall be loaded and imported into the current namespace when us use <code>from package import *</code>.</p>\n\n<p>The big difference is, that when you <em>omit</em> the declaration of <code>__all__</code> in a package\'s <code>__init__.py</code>, the statement <code>from package import *</code> will not import anything at all (with exceptions explained in the documentation, see link above). </p>\n\n<p>On the other hand, if you omit <code>__all__</code> in a module, the "starred import" will import all names (not starting with an underscore) defined in the module.</p>\n'}, {'answer_id': 35710527, 'author': 'Russia Must Remove Putin', 'author_id': 541136, 'author_profile': 'https://Stackoverflow.com/users/541136', 'pm_score': 9, 'selected': False, 'text': '<blockquote>\n<p><strong>Explain <strong>all</strong> in Python?</strong></p>\n<p>I keep seeing the variable <code>__all__</code> set in different <code>__init__.py</code> files.</p>\n<p>What does this do?</p>\n</blockquote>\n<h2>What does <code>__all__</code> do?</h2>\n<p>It declares the semantically &quot;public&quot; names from a module. If there is a name in <code>__all__</code>, users are expected to use it, and they can have the expectation that it will not change.</p>\n<p>It also will have programmatic effects:</p>\n<h3><code>import *</code></h3>\n<p><code>__all__</code> in a module, e.g. <code>module.py</code>:</p>\n<pre><code>__all__ = [\'foo\', \'Bar\']\n</code></pre>\n<p>means that when you <code>import *</code> from the module, only those names in the <code>__all__</code> are imported:</p>\n<pre><code>from module import *               # imports foo and Bar\n</code></pre>\n<h3>Documentation tools</h3>\n<p>Documentation and code autocompletion tools may (in fact, should) also inspect the <code>__all__</code> to determine what names to show as available from a module.</p>\n<h2><code>__init__.py</code> makes a directory a Python package</h2>\n<p>From the <a href="https://docs.python.org/tutorial/modules.html#packages" rel="noreferrer">docs</a>:</p>\n<blockquote>\n<p>The <code>__init__.py</code> files are required to make Python treat the directories as containing packages; this is done to prevent directories with a common name, such as string, from unintentionally hiding valid modules that occur later on the module search path.</p>\n</blockquote>\n<blockquote>\n<p>In the simplest case, <code>__init__.py</code> can just be an empty file, but it can also execute initialization code for the package or set the <code>__all__</code> variable.</p>\n</blockquote>\n<p>So the <code>__init__.py</code> can declare the <code>__all__</code> for a <em>package</em>.</p>\n<h1>Managing an API:</h1>\n<p>A package is typically made up of modules that may import one another, but that are necessarily tied together with an <code>__init__.py</code> file. That file is what makes the directory an actual Python package. For example, say you have the following files in a package:</p>\n<pre class="lang-none prettyprint-override"><code>package\n├── __init__.py\n├── module_1.py\n└── module_2.py\n</code></pre>\n<p>Let\'s create these files with Python so you can follow along - you could paste the following into a Python 3 shell:</p>\n<pre><code>from pathlib import Path\n\npackage = Path(\'package\')\npackage.mkdir()\n\n(package / \'__init__.py\').write_text(&quot;&quot;&quot;\nfrom .module_1 import *\nfrom .module_2 import *\n&quot;&quot;&quot;)\n\npackage_module_1 = package / \'module_1.py\'\npackage_module_1.write_text(&quot;&quot;&quot;\n__all__ = [\'foo\']\nimp_detail1 = imp_detail2 = imp_detail3 = None\ndef foo(): pass\n&quot;&quot;&quot;)\n\npackage_module_2 = package / \'module_2.py\'\npackage_module_2.write_text(&quot;&quot;&quot;\n__all__ = [\'Bar\']\nimp_detail1 = imp_detail2 = imp_detail3 = None\nclass Bar: pass\n&quot;&quot;&quot;)\n</code></pre>\n<p>And now you have presented a complete api that someone else can use when they import your package, like so:</p>\n<pre><code>import package\npackage.foo()\npackage.Bar()\n</code></pre>\n<p>And the package won\'t have all the other implementation details you used when creating your modules cluttering up the <code>package</code> namespace.</p>\n<h2><code>__all__</code> in <code>__init__.py</code></h2>\n<p>After more work, maybe you\'ve decided that the modules are too big (like many thousands of lines?) and need to be split up. So you do the following:</p>\n<pre class="lang-none prettyprint-override"><code>package\n├── __init__.py\n├── module_1\n│\xa0\xa0 ├── foo_implementation.py\n│\xa0\xa0 └── __init__.py\n└── module_2\n    ├── Bar_implementation.py\n    └── __init__.py\n</code></pre>\n<p>First make the subpackage directories with the same names as the modules:</p>\n<pre><code>subpackage_1 = package / \'module_1\'\nsubpackage_1.mkdir()\nsubpackage_2 = package / \'module_2\'\nsubpackage_2.mkdir()\n</code></pre>\n<p>Move the implementations:</p>\n<pre><code>package_module_1.rename(subpackage_1 / \'foo_implementation.py\')\npackage_module_2.rename(subpackage_2 / \'Bar_implementation.py\')\n</code></pre>\n<p>create <code>__init__.py</code>s for the subpackages that declare the <code>__all__</code> for each:</p>\n<pre><code>(subpackage_1 / \'__init__.py\').write_text(&quot;&quot;&quot;\nfrom .foo_implementation import *\n__all__ = [\'foo\']\n&quot;&quot;&quot;)\n(subpackage_2 / \'__init__.py\').write_text(&quot;&quot;&quot;\nfrom .Bar_implementation import *\n__all__ = [\'Bar\']\n&quot;&quot;&quot;)\n</code></pre>\n<p>And now you still have the api provisioned at the package level:</p>\n<pre><code>&gt;&gt;&gt; import package\n&gt;&gt;&gt; package.foo()\n&gt;&gt;&gt; package.Bar()\n&lt;package.module_2.Bar_implementation.Bar object at 0x7f0c2349d210&gt;\n</code></pre>\n<p>And you can easily add things to your API that you can manage at the subpackage level instead of the subpackage\'s module level. If you want to add a new name to the API, you simply update the <code>__init__.py</code>, e.g. in module_2:</p>\n<pre><code>from .Bar_implementation import *\nfrom .Baz_implementation import *\n__all__ = [\'Bar\', \'Baz\']\n</code></pre>\n<p>And if you\'re not ready to publish <code>Baz</code> in the top level API, in your top level <code>__init__.py</code> you could have:</p>\n<pre><code>from .module_1 import *       # also constrained by __all__\'s\nfrom .module_2 import *       # in the __init__.py\'s\n__all__ = [\'foo\', \'Bar\']     # further constraining the names advertised\n</code></pre>\n<p>and if your users are aware of the availability of <code>Baz</code>, they can use it:</p>\n<pre><code>import package\npackage.Baz()\n</code></pre>\n<p>but if they don\'t know about it, other tools (like <a href="https://hg.python.org/cpython/file/2.7/Lib/pydoc.py#l173" rel="noreferrer">pydoc</a>) won\'t inform them.</p>\n<p>You can later change that when <code>Baz</code> is ready for prime time:</p>\n<pre><code>from .module_1 import *\nfrom .module_2 import *\n__all__ = [\'foo\', \'Bar\', \'Baz\']\n</code></pre>\n<h1>Prefixing <code>_</code> versus <code>__all__</code>:</h1>\n<p>By default, Python will export all names that do not start with an <code>_</code> when imported with <code>import *</code>. As demonstrated by the shell session here, <code>import *</code> does not bring in the <code>_us_non_public</code> name from the <code>us.py</code> module:</p>\n<pre class="lang-py prettyprint-override"><code>$ cat us.py\nUSALLCAPS = &quot;all caps&quot;\nus_snake_case = &quot;snake_case&quot;\n_us_non_public = &quot;shouldn\'t import&quot;\n$ python\nPython 3.10.0 (default, Oct  4 2021, 17:55:55) [GCC 10.3.0] on linux\nType &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;license&quot; for more information.\n&gt;&gt;&gt; from us import *\n&gt;&gt;&gt; dir()\n[\'USALLCAPS\', \'__annotations__\', \'__builtins__\', \'__doc__\', \'__loader__\', \'__name__\', \'__package__\', \'__spec__\', \'us_snake_case\']\n</code></pre>\n<p>You certainly <em>could</em> rely on this mechanism. Some packages in the Python standard library, in fact, <em>do</em> rely on this, but to do so, they alias their imports, for example, in <a href="https://hg.python.org/cpython/file/default/Lib/ctypes/__init__.py#l3" rel="noreferrer"><code>ctypes/__init__.py</code></a>:</p>\n<pre><code>import os as _os, sys as _sys\n</code></pre>\n<p>Using the <code>_</code> convention can be more elegant because it removes the redundancy of naming the names again. But it adds the redundancy for imports (if you have a lot of them) and it is <em>easy</em> to forget to do this consistently - and the last thing you want is to have to indefinitely support something you intended to only be an implementation detail, just because you forgot to prefix an <code>_</code> when naming a function.</p>\n<p>I personally write an <code>__all__</code> early in my development lifecycle for modules so that others who might use my code know what they should use and not use.</p>\n<p>Most packages in the standard library also use <code>__all__</code>.</p>\n<h1>When avoiding <code>__all__</code> makes sense</h1>\n<p>It makes sense to stick to the <code>_</code> prefix convention in lieu of <code>__all__</code> when:</p>\n<ul>\n<li>You\'re still in early development mode and have no users, and are constantly tweaking your API.</li>\n<li>Maybe you do have users, but you have unittests that cover the API, and you\'re still actively adding to the API and tweaking in development.</li>\n</ul>\n<h1>An <code>export</code> decorator</h1>\n<p>The downside of using <code>__all__</code> is that you have to write the names of functions and classes being exported twice - and the information is kept separate from the definitions. We <em>could</em> use a decorator to solve this problem.</p>\n<p>I got the idea for such an export decorator from David Beazley\'s talk on packaging. This implementation seems to work well in CPython\'s traditional importer. If you have a special import hook or system, I do not guarantee it, but if you adopt it, it is fairly trivial to back out - you\'ll just need to manually add the names back into the <code>__all__</code></p>\n<p>So in, for example, a utility library, you would define the decorator:</p>\n<pre><code>import sys\n\ndef export(fn):\n    mod = sys.modules[fn.__module__]\n    if hasattr(mod, \'__all__\'):\n        mod.__all__.append(fn.__name__)\n    else:\n        mod.__all__ = [fn.__name__]\n    return fn\n</code></pre>\n<p>and then, where you would define an <code>__all__</code>, you do this:</p>\n<pre><code>$ cat &gt; main.py\nfrom lib import export\n__all__ = [] # optional - we create a list if __all__ is not there.\n\n@export\ndef foo(): pass\n\n@export\ndef bar():\n    \'bar\'\n\ndef main():\n    print(\'main\')\n\nif __name__ == \'__main__\':\n    main()\n</code></pre>\n<p>And this works fine whether run as main or imported by another function.</p>\n<pre><code>$ cat &gt; run.py\nimport main\nmain.main()\n\n$ python run.py\nmain\n</code></pre>\n<p>And API provisioning with <code>import *</code> will work too:</p>\n<pre><code>$ cat &gt; run.py\nfrom main import *\nfoo()\nbar()\nmain() # expected to error here, not exported\n\n$ python run.py\nTraceback (most recent call last):\n  File &quot;run.py&quot;, line 4, in &lt;module&gt;\n    main() # expected to error here, not exported\nNameError: name \'main\' is not defined\n</code></pre>\n'}, {'answer_id': 36119040, 'author': 'Bob Stein', 'author_id': 673991, 'author_profile': 'https://Stackoverflow.com/users/673991', 'pm_score': 6, 'selected': False, 'text': '<p><code>__all__</code> customizes <code>*</code> in <a href="https://docs.python.org/2/tutorial/modules.html#more-on-modules" rel="noreferrer"><code>from &lt;module&gt; import *</code></a>\nand <a href="https://docs.python.org/2/tutorial/modules.html#importing-from-a-package" rel="noreferrer"><code>from &lt;package&gt; import *</code></a>.</p>\n<hr />\n<p>A <a href="https://stackoverflow.com/a/7948504/673991">module</a> is a <code>.py</code> file meant to be imported.</p>\n<p>A <a href="https://stackoverflow.com/a/7948504/673991">package</a> is a directory with a <code>__init__.py</code> file. A package usually contains modules.</p>\n<hr />\n<h1>MODULES</h1>\n<pre><code>&quot;&quot;&quot; cheese.py - an example module &quot;&quot;&quot;\n\n__all__ = [\'swiss\', \'cheddar\']\n\nswiss = 4.99\ncheddar = 3.99\ngouda = 10.99\n</code></pre>\n<p><code>__all__</code> lets humans know the &quot;public&quot; features of a <strong>module</strong>.<sup>[<a href="https://stackoverflow.com/a/35710527/673991" title="thanks Aaron Hall">@AaronHall</a>]</sup>  Also, pydoc recognizes them.<sup>[<a href="https://stackoverflow.com/a/2838800/673991" title="thanks @Longpoke">@Longpoke</a>]</sup></p>\n<h2>from <em>module</em> import *</h2>\n<p>See how <code>swiss</code> and <code>cheddar</code> are brought into the local namespace, but not <code>gouda</code>:</p>\n<pre><code>&gt;&gt;&gt; from cheese import *\n&gt;&gt;&gt; swiss, cheddar\n(4.99, 3.99)\n&gt;&gt;&gt; gouda\nTraceback (most recent call last):\n  File &quot;&lt;stdin&gt;&quot;, line 1, in &lt;module&gt;\nNameError: name \'gouda\' is not defined\n</code></pre>\n<p>Without <code>__all__</code>, any symbol (that doesn\'t start with an underscore) would have been available.</p>\n<hr />\n<h1>Imports without <code>*</code> are not affected by <code>__all__</code></h1>\n<hr />\n<h2>import <em>module</em></h2>\n<pre><code>&gt;&gt;&gt; import cheese\n&gt;&gt;&gt; cheese.swiss, cheese.cheddar, cheese.gouda\n(4.99, 3.99, 10.99)\n</code></pre>\n<h2>from <em>module</em> import <em>names</em></h2>\n<pre><code>&gt;&gt;&gt; from cheese import swiss, cheddar, gouda\n&gt;&gt;&gt; swiss, cheddar, gouda\n(4.99, 3.99, 10.99)\n</code></pre>\n<h2>import <em>module</em> as <em>localname</em></h2>\n<pre><code>&gt;&gt;&gt; import cheese as ch\n&gt;&gt;&gt; ch.swiss, ch.cheddar, ch.gouda\n(4.99, 3.99, 10.99)\n</code></pre>\n<hr />\n<h1>PACKAGES</h1>\n<p>In the <code>__init__.py</code> file of a <strong>package</strong> <code>__all__</code> is a list of strings with the names of public modules or other objects. Those features are available to wildcard imports. As with modules, <code>__all__</code> customizes the <code>*</code> when wildcard-importing from the package.<sup>[<a href="https://stackoverflow.com/a/16595377/673991" title="thanks @MartinStettner">@MartinStettner</a>]</sup></p>\n<p>Here\'s an excerpt from the <a href="https://dev.mysql.com/doc/connector-python/en/" rel="noreferrer">Python MySQL Connector</a> <code>__init__.py</code>:</p>\n<pre><code>__all__ = [\n    \'MySQLConnection\', \'Connect\', \'custom_error_exception\',\n\n    # Some useful constants\n    \'FieldType\', \'FieldFlag\', \'ClientFlag\', \'CharacterSet\', \'RefreshOption\',\n    \'HAVE_CEXT\',\n\n    # Error handling\n    \'Error\', \'Warning\',\n\n    ...etc...\n\n    ]\n</code></pre>\n<p>The default case, <a href="https://docs.python.org/tutorial/modules.html#importing-from-a-package" rel="noreferrer">asterisk with no <code>__all__</code> for a package</a>, is complicated, because the obvious behavior would be expensive: to use the file system to search for all modules in the package. Instead, in my reading of the docs, only the objects defined in <code>__init__.py</code> are imported:</p>\n<blockquote>\n<p>If <code>__all__</code> is not defined, the statement <code>from sound.effects import *</code> does <em>not</em> import all submodules from the package <code>sound.effects</code> into the current namespace; it only ensures that the package <code>sound.effects</code> has been imported (possibly running any initialization code in <code>__init__.py</code>) and then imports whatever names are defined in the package. This includes any names defined (and submodules explicitly loaded) by <code>__init__.py</code>. It also includes any submodules of the package that were explicitly loaded by previous import statements.</p>\n</blockquote>\n<hr />\n<p>And lastly, a venerated tradition for stack overflow answers, professors, and mansplainers everywhere, is the <em>bon mot</em> of reproach for asking a question in the first place:</p>\n<blockquote>\n<p>Wildcard imports ... should be avoided, as they [confuse] readers and many automated tools.</p>\n</blockquote>\n<p><sup>[<a href="https://www.python.org/dev/peps/pep-0008/#imports" rel="noreferrer" title="see PEP 8, as noted by @ToolmakerSteve">PEP 8</a>, @ToolmakerSteve]</sup></p>\n'}, {'answer_id': 36853901, 'author': 'Mihai Capotă', 'author_id': 200234, 'author_profile': 'https://Stackoverflow.com/users/200234', 'pm_score': 4, 'selected': False, 'text': '<p><code>__all__</code> is used to document the public API of a Python module. Although it is optional, <code>__all__</code> should be used.</p>\n<p>Here is the relevant excerpt from <a href="https://docs.python.org/3/reference/simple_stmts.html#the-import-statement" rel="noreferrer">the Python language reference</a>:</p>\n<blockquote>\n<p>The public names defined by a module are determined by checking the module’s namespace for a variable named <code>__all__</code>; if defined, it must be a sequence of strings which are names defined or imported by that module. The names given in <code>__all__</code> are all considered public and are required to exist. If <code>__all__</code> is not defined, the set of public names includes all names found in the module’s namespace which do not begin with an underscore character (\'_\'). <code>__all__</code> should contain the entire public API. It is intended to avoid accidentally exporting items that are not part of the API (such as library modules which were imported and used within the module).</p>\n</blockquote>\n<p><a href="https://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces" rel="noreferrer">PEP 8</a> uses similar wording, although it also makes it clear that imported names are not part of the public API when <code>__all__</code> is absent:</p>\n<blockquote>\n<p>To better support introspection, modules should explicitly declare the names in their public API using the <code>__all__</code> attribute. Setting <code>__all__</code> to an empty list indicates that the module has no public API.</p>\n<p>[...]</p>\n<p>Imported names should always be considered an implementation detail. Other modules must not rely on indirect access to such imported names unless they are an explicitly documented part of the containing module\'s API, such as <code>os.path</code> or a package\'s <code>__init__</code> module that exposes functionality from submodules.</p>\n</blockquote>\n<p>Furthermore, as pointed out in other answers, <code>__all__</code> is used to enable <a href="https://docs.python.org/3/tutorial/modules.html#importing-from-a-package" rel="noreferrer">wildcard importing for packages</a>:</p>\n<blockquote>\n<p>The import statement uses the following convention: if a package’s <code>__init__.py</code> code defines a list named <code>__all__</code>, it is taken to be the list of module names that should be imported when <code>from package import *</code> is encountered.</p>\n</blockquote>\n'}, {'answer_id': 49620866, 'author': 'Cyker', 'author_id': 418966, 'author_profile': 'https://Stackoverflow.com/users/418966', 'pm_score': 4, 'selected': False, 'text': '<h1>Short answer</h1>\n\n<p><code>__all__</code> affects <code>from &lt;module&gt; import *</code> statements.</p>\n\n<h1>Long answer</h1>\n\n<p>Consider this example:</p>\n\n<pre><code>foo\n├── bar.py\n└── __init__.py\n</code></pre>\n\n<p>In <code>foo/__init__.py</code>:</p>\n\n<ul>\n<li><p>(Implicit) If we don\'t define <code>__all__</code>, then <code>from foo import *</code> will only import names defined in <code>foo/__init__.py</code>.</p></li>\n<li><p>(Explicit) If we define <code>__all__ = []</code>, then <code>from foo import *</code> will import nothing.</p></li>\n<li><p>(Explicit) If we define <code>__all__ = [ &lt;name1&gt;, ... ]</code>, then <code>from foo import *</code> will only import those names.</p></li>\n</ul>\n\n<p>Note that in the implicit case, python won\'t import names starting with <code>_</code>. However, you can force importing such names using <code>__all__</code>.</p>\n\n<p>You can view the Python document <a href="https://docs.python.org/3/tutorial/modules.html#importing-from-a-package" rel="noreferrer">here</a>.</p>\n'}, {'answer_id': 54112742, 'author': 'Eugene Yarmash', 'author_id': 244297, 'author_profile': 'https://Stackoverflow.com/users/244297', 'pm_score': 3, 'selected': False, 'text': '<p><code>__all__</code> affects how <code>from foo import *</code> works.</p>\n\n<p>Code that is inside a module body (but not in the body of a function or class) may use an asterisk (<code>*</code>) in a <code>from</code> statement:</p>\n\n<pre><code>from foo import *\n</code></pre>\n\n<p>The <code>*</code> requests that all attributes of module <code>foo</code> (except those beginning with underscores) be bound as global variables in the importing module. When <code>foo</code> has an attribute <code>__all__</code>, the attribute\'s value is the list of the names that are bound by this type of <code>from</code> statement. </p>\n\n<p>If <code>foo</code> is a <em>package</em> and its <code>__init__.py</code> defines a list named <code>__all__</code>, it is taken to be the list of submodule names that should be imported when <code>from foo import *</code> is encountered. If <code>__all__</code> is not defined, the statement <code>from foo import *</code> imports whatever names are defined in the package. This includes any names defined (and submodules explicitly loaded) by <code>__init__.py</code>.</p>\n\n<p>Note that <code>__all__</code> doesn\'t have to be a list. As per the documentation on the <a href="https://docs.python.org/3/reference/simple_stmts.html#the-import-statement" rel="noreferrer"><code>import</code> statement</a>, if defined, <code>__all__</code> must be a <em>sequence of strings</em> which are names defined or imported by the module. So you may as well use a tuple to <a href="https://stackoverflow.com/a/22140115/244297">save</a> some memory and CPU cycles. Just don\'t forget a comma in case the module defines a single public name:</p>\n\n<pre><code>__all__ = (\'some_name\',)\n</code></pre>\n\n<p>See also <a href="https://stackoverflow.com/q/2386714/244297">Why is “import *” bad?</a></p>\n'}, {'answer_id': 56636531, 'author': 'prosti', 'author_id': 5884955, 'author_profile': 'https://Stackoverflow.com/users/5884955', 'pm_score': 2, 'selected': False, 'text': '<p>This is defined in PEP8 <a href="https://www.python.org/dev/peps/pep-0008/#global-variable-names" rel="nofollow noreferrer">here</a>:</p>\n<blockquote>\n<p>Global Variable Names</p>\n<p>(Let\'s hope that these variables are meant for use inside one module only.) The conventions are about the same as those for functions.</p>\n<p>Modules that are designed for use via <code>from M import *</code> should use the <code>__all__</code> mechanism to prevent exporting globals, or use the older convention of prefixing such globals with an underscore (which you might want to do to indicate these globals are &quot;module non-public&quot;).</p>\n</blockquote>\n<p>PEP8 provides coding conventions for the Python code comprising the standard library in the main Python distribution. The more you follow this, closer you are to the original intent.</p>\n'}]
['https://Stackoverflow.com/questions/44834', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/1794/']