call __init__() in modules at init time

[JeffBezanson]

The improvement here should be obvious. Less duplication, more locality, etc.

This will also make it very easy for packages to support precompilation.

This does the simplest thing that could work, leaving the following unsolved:

• Order of initialization (though there is a stack, such that outer modules are initialized before inner)
• Idempotence (though the system itself will not try to init a module more than once)

[StefanKarpinski]

This rather sneakily sets a precedent about reserved names, implicitly make _name the de facto standard pattern. It might be better to do something like __init__.

[JeffBezanson]

That name is fine with me.

[vtjnash]

why is this order best?

are you waiting to init inner modules until after the outer module is init, or before it is init, but after it is closed?

[JeffBezanson]

I think officially, the order has to be undefined for now, since we have no way to guarantee it after deserialization. But I tried to pick an approach that would be less likely to cause problems.

Inner modules should be init after all their outer modules are closed, so they don't try to refer to something that might not have been defined yet. I also init outer modules first, but that's less important.