← Back to team overview

launchpad-dev team mailing list archive

Re: Huge success! No more globs in canonical/launchpad/interfaces/__init__.py

 

On Wed, Nov 10, 2010 at 2:33 PM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> On 11/10/2010 08:53 AM, Jonathan Lange wrote:
>> It is in your interest as a Launchpad hacker to never write an
>> __init__.py that just imports a bunch of stuff using globs.
>
> You make it sound like globs are a key component of the problem.  Would
> writing an __ini__.py that just imports a bunch of stuff without using
> globs avoid the technical issues?
>

Well, that's partly because I've made a couple of packages that do
non-glob __init__.py re-exports that seem to work OK
(lp.codehosting.vfs, testtools).  I'm still not convinced it's a good
idea, but I can't condemn the practice as roundly as glob re-exports.
I think there's a place for using re-exports to carefully control the
namespace of a public module.

Globs do make it much worse though, since they make static analysis
harder, which in turn makes figuring out dependencies harder, and
since they can easily lead to implicit registration of things (like
they were in Launchpad for webservice APIs).

Certainly, using __init__.py glob-or-no is a large part of the
problem, because you can't get at any of the modules within a package
without first evaluating that package's __init__.py.  Twisted has long
had a ban on anything other than docstrings in __init__.py for this
very reason.

jml



References