In case a non-Python programmer is reading this and misunderstood your comment, I'll point out that having code in __init__.py and having import-time side effects are completely unrelated.

When I put any code in __init__.py, it's usually just to make the import path shorter for the programmer using my library. So instead of this:

from mypackage.models import Foo

...users can do this:

from mypackage import Foo

And all it takes to support that is putting this in mypackage/__init__.py:

from mypackage.models import Foo

A quick Googling of "Should I put code in __init__.py" shows a lot of people doing that same pattern. It doesn't show a consensus of people saying that more substantial code in __init__.py is an anti-pattern.

To me you're using __init__.py right. The person who wrote the library I mentioned really isn't.

It's like programmers who find out about metaprogramming. Usually they grow out of it.

I haven't grown out of metaprogramming at all. I just try and use it only when it's the best option. Usually because it means reducing duplication.

I liked metaprogramming to an extent in C++. I _love_ it in D.

Replace "best option" with "only practical option" and you're good to go.

That may depend on the language you are using.

In Perl, I find metaprogramming to be extremely powerful. I don't go too deep into Class::MOP usually. However, I do find that focusing on tooling before code is usually a net win. This means a lot of work can be done by writing DSL's that use metaprogramming behind the scenes. It works well and has become a common approach for certain kind of things (like object frameworks).

I'm not saying you should never use metaprogramming. Sometimes there is no other (practical) way. But it can be easily abused, often for a little added convenience but a much larger conceptual complexity and additional debugging issues. Why have a well-designed API when you can have a metaprogrammmed mess instead?