<div class="gmail_quote">On Wed, Jun 27, 2012 at 10:57 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For complex stuff, subpackages<br>
("import X.Y") might be needed, but that's rare (and even then, key<br>
names should be exposed directly from X).<br>
<span class="HOEnZb"><font color="#888888"><br>
Paul.<br>
</font></span><br>
PS Having said all this, I don't maintain any code on PyPI - I'm a<br>
user not a producer. That may affect my perspective...<br></blockquote><div><br>That, and if you don't work with web stuff or networking stuff. Things having lots of subpackages are quite the rule there.<br><br>Also, functional naming for top-level modules is actually an anti-pattern: an invitation to naming conflicts, especially with future stdlib contents. Suppose two people want to write an "email" package? Unless you jam the ownership into the name (e.g. joes_email and bobs_email), what are you supposed to do?<br>
<br>This is why we have popular packages with names like nose and celery and django and pyramid and lamson: because unique memorable names > functionally descriptive names.<br><br><br><br></div></div>