<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
>> An implication of all this is that if now I wanted to create a new<br>
>> module x.y.z.w, this means that the previously "leaf"-module x.y.z<br>
>> would become "non-leaf".  In other words, I'd have to:<br>
>><br>
>> 1. create the new directory x/y/z<br>
>> 2. *rename* the file x/y/z.py to x/y/z/__init__.py<br>
>> 3. create the file x/y/z/w.py to hold the source for the new x.y.z.w<br>
>>    module<br>
<br>
</div><div class="im">>With regard to point 2 -- would it be possible to just move z.py into<br>
>x/y/z, and put 'from z import *' into x/y/z/__init__.py, for the same<br>
>effect? Or is that not a good idea?<br>
<br>
</div>I think in this case what you would need is something like 'from<br>
..z import *', but this does not work either; one gets the error<br>
"SyntaxError: 'import *' not allowed with 'from .'".<br></blockquote><div><br></div><div>If you have a "spam.ham" module and you want to refactor it into a package, there's basically two common things to do as you've discovered.</div>

<div><br></div><div>The first is to turn ham into a package: that entails creating a directory named ham, and moving ham.py to ham/__init__.py</div><div><br></div><div>That works fine and is used by a number of people: I personally hate doing it, though. I don't like to put significant chunks of code into __init__.py, but instead just code which largely handles... namespace-issues or bootstrapping of a package. Partly for the reason you specified: it makes life a little annoying to have multiple files with completely different content have the same filename even if they aren't ambiguous due to directories. </div>

<div><br></div><div>I personally MUCH prefer turning ham into a package, and moving the original "ham.py" to spam/ham/_ham.py. In spam/ham/__init__.py, I'd then do:</div><div><br></div><div>from spam.ham._ham import *</div>

<div> </div><div>From a usage perspective, everything that used to be in spam.ham will still be there with all the contents you'd expect (the stuff in spam/ham/_ham.py)... and people can import spam.ham.eggs if they want or need to access those details.</div>

<div><br></div><div>(I get around the above traceback you mention by just using an absolute import -- but I never use relative imports, anyways. They make my soul cry from a style and management and sanity perspective.)</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">A third solution would be to change step 2 above to this:<br>
<br>
2. create the *symlink* x/y/z/__init__.py --> ../z.py<br></blockquote><div><br></div><div>This is IMHO a very, very, very bad idea :)</div><div><br></div><div>Yes, it'll work. But involving symlinks will make everything from distribution to revision control a bit more complicated (even if you're never intending any Windows users to use it or use a system like svn which handles symlinks adequately).</div>

<div><br></div><div>It'll just create, in essence, two separate files on your system with the same content/code. Sure they're not really two separate files, but as far as Python knows they are.</div><div><br></div>

<div>It just seems like it's asking for trouble :)</div><div><br></div><div>--S</div></div>