title: About python package structure - elements per module
body: <p>Is there any objective, strong argument against having a file for each group of correlated modules instead of heavily packaging them in a single module? For example, say I have a subpackage named <code>utils</code>, and one of the utilities it provides is regarding input and output of data. What I mean is if it's wrong to put big functions (with their important related subfunctions) in "private" modules and then call them via importing the main module <code>io</code>.</p>
  
  <pre><code>utils/
    io.py
    _pprint.py
    _ptable.py
  </code></pre>
  
  <p>Say <code>_pprint</code> is a big method that requires some other little sub-methods, then those would be in the <code>_pprint.py</code> module as well, because they're heavily correlated.</p>
  
  <p>Basically, the issue is that I have a <code>io.py</code> module (and some others) with 20 functions that are a pain to read/scroll through to find some specific ones I want to change. I would like to have (as an example) an <code>io</code> module that can be called via <code>import package.io</code> and then, inside <code>io.py</code>, it imports the other modules that are related to I/O, or something like that (maybe I would need to do this with subpackages instead, to use more <code>__init__.py</code>'s).</p>