title: What is the downside of adding '__init__.py' in sub-directories of a Python codebase if certain directories do not have that file?
body: <p>Since Python 3.3, the compulsion for having an <code>__init__.py</code> in every directory of a source code was removed. My aim is to read all the modules and submodules of a given source code using <code>pyclbr</code>. However, there are certain cases where a particular module is a submodule to other modules and not all the parent modules are packages. <code>pyclbr</code> does not understand the difference between directories and packages.</p>
  <p>So, while <a href="https://stackoverflow.com/questions/62237157/how-to-use-pyclbr-for-nested-modules/66298227#66298227">attempting to solve this problem</a>, I thought of adding the <code>__init__.py</code> file in every directory that is not a package. I am not sure as to what the downsides are. I have this inhibition of deviating from the standards set by the Python community and that might result in incorrectness sometime later.</p>
  <p>As stated in the above hyperlink, I could go with specifying only the module and give its full-path to <code>pyclbr</code> but that does not work in cases like the following source code structure:</p>
  <pre><code>(gruml) ➜  gruml git:(run-sequence-diagram) ✗ tree a
  a
  └── a
      └── a
          ├── __init__.py
          └── a.py
  
  2 directories, 2 files
  </code></pre>
  <p>This does not work because sending <code>a</code> to <code>pyclbr</code> would return the same data for <code>a.a.a</code> and for <code>a.a.a.a</code>. So, I have to send the full-module path and work for directories.</p>