title: Python: sharing common code among a family of scripts
body: <p>I'm writing a family of Python scripts within a project; each script is within a subdirectory of the project, like so:</p>
  
  <pre><code>projectroot
    |
    |- subproject1
    |    |
    |    |- script1.main.py
    |    `- script1.merger.py
    |
    |- subproject2
    |    |
    |    |- script2.main.py
    |    |- script2.matcher.py
    |    `- script2.merger.py
    |
    `- subproject3
         |
         |- script3.main.py
         |- script3.converter.py
         |- script3.matcher.py
         `- script3.merger.py
  </code></pre>
  
  <p>Now several of the scripts share some code.  The shared code is best considered part of the project itself, and not something I would compile separately and make a library out of, or drop in a sitewide PYTHONPATH.  I could place that code in various places, such as in the <code>projectroot</code> directory itself, or in a child directory of <code>projectroot</code> called <code>common</code> (perhaps).</p>
  
  <p>However, most of the ways I have thought of so far involve making packages out of my subprojects with empty <code>__init__.py</code> files and using relative imports (or redundantly messing with <code>sys.path</code> in every subproject.  Worse, it seems like building a package structure around this family of scripts runs afoul of the following warning from the rejected <a href="https://www.python.org/dev/peps/pep-3122/" rel="noreferrer">PEP-3122</a>:</p>
  
  <blockquote>
    <p>Attention! This PEP has been rejected. Guido views running scripts within a package as an anti-pattern.</p>
  </blockquote>
  
  <p>If scripts within a package is anti-patternish, how can I set things up in a way which keeps the common code in the same project?  Or is a module and package-based system acceptable here?  Which is the cleanest approach?  (FWIW I would prefer to have a file such as <code>shared.py</code> or <code>common.py</code> in the project root directory, rather than making a utility directory that is a sibling to the "real" subprojects.)</p>