title: How do I resolve namespace conflicts in my Python packages with standard library package names?
body: <p>I am developing a package with the following structure on disk:</p>
  
  <pre><code>foo/
     __init__.py
     xml.py
     bar.py
     moo.py
  </code></pre>
  
  <p>The <code>xml.py</code> package provides a class that does some custom XML parsing and translation for the other package components using a SAX stream parser. So it has in it:</p>
  
  <pre><code>import xml.sax
  import xml.sax.handler
  </code></pre>
  
  <p>But when I go to use <code>foo.xml</code> in an application I get:</p>
  
  <pre><code>Traceback (most recent call last):
    File "testxmlparser.py", line 15, in &lt;module&gt;
      import foo.xml
    File "~/code/foo/xml.py", line 39, in &lt;module&gt;
      import xml.sax
  ImportError: No module named sax
  </code></pre>
  
  <p>I appear to have a namespace conflict. If I rename <code>xml.py</code> to something else like <code>xmlparser.py</code> everything works as expected. But this feels like the wrong thing to do. I feel like I'm missing something fundamental about package names and resolution in Python here.</p>
  
  <p>Is there a proper way to make this work that doesn't involve me renaming the <code>foo/xml.py</code> file? Or is that really the only solution to the conflicting names?</p>
  
  <p>Edit: The "avoid naming things the same as standard Python modules" seems...well..a mineshaft to me. That's a moving target, the standard module set, that's bound to change and grow over time. So unless you get <em>really</em> creative with your names the rename-things-until-you-find-something-that-doesn't-conflict solutions seems poor to me. Besides, I've got it in a unique package name with <code>foo</code> already (I'm not using <code>foo</code>, but something that is definitely unique), shouldn't that be enough?</p>