PyWart: "Python's import statement and the history of external dependencies"

Rick Johnson rantingrickjohnson at gmail.com
Sat Nov 22 02:48:51 CET 2014


On Friday, November 21, 2014 6:33:32 PM UTC-6, Ian wrote:
> On Fri, Nov 21, 2014 at 3:25 PM, Rick Johnson
> > Why does the code in the main package need to run when i
> > *explicitly* and *directly* fetched a "nested resource"
> > within the package?[...]
> 
> It has nothing to do with the __init__ file specifically.
> When you import ham.spam.eggs [...]  Would you expect to
> be able to create a class instance and call one of its
> methods without having the __init__ method called?

Not an "instance method", but a "class method", yes! ;-)

Just as Objects have both class level *AND* instance level
scoping for methods, so too should packages -- in a
different sort of way of course. 

> If you don't want any initialization to happen when you
> import your modules, then don't put any initialization
> code in your __init__.py. Or use namespace packages as
> mentioned above.

Ha, that's what i realized after being caught in the
"__init__ nightmare" not too long ago :). But now I have my
deeply nested module namespaces working just fine under
Python 2.x. although i feel like the system is too clunky
and in need of refining. Maybe "namespace packages" are what
i need, although i see they are Python 3.x only. :-(

In any event, thanks for taking the time to explain the
details. I feel i understand the systems much better now.
Your "coconut example" was the key to my understanding. And
now, i can stand on the top of the mountain and see how the
system works -- I no longer have this damn mountain
blocking my view. 

I think Python's import and packaging systems are both very
"good ideas" that just happen to be covered in a blanket of
dust, and all we need to do it give then a good cleaning to
bring out that showroom shine -- and detailing is my
specialty!



More information about the Python-list mailing list