NameError in cross imports of modules

[Jay O'Connor]

Thomas Wouters wrote:

> 
> Well, I already made clear here that the answer is 'no' :-) I'm not sure
> what kind of situation you are in when you say you are 'importing classes'
> (I've never done that, myself, and it's only possible since Python 2.1 in
> any case :),

I was careless in my terminology, I meant importing a module for the
sake of access to the classes the module contains.

> but 'from module import *' imports a lot more than classes, and
> can do all kinds of nasty things, like shadowing builtins and globals, and
> clobbering your own variables. If you want to import a couple of class names
> from a module to your own namespace, you best name them explicitly, so you
> are sure those are the only names imported. And more importantly, so that
> you, and everyone else, can always find out where a name comes from. For
> instance:
> 
> from spamsong import *
> 
> <X lines of code>
> 
> from Eric import *
> 
> <several hundred lines of code>
> 
> class ExtendedViking(Viking):
>     <lots of code relying on what Viking is>
> 
> Where did the 'Viking' come from ? Everyone knows both the spamsong and Eric
> the Viking feature Vikings. Maybe spamsong named its viking differently when
> you first wrote the module, or you never noticed spamsong had a viking
> because it was always overwritten by the one in Eric. Or maybe it's the
> other way 'round, you intended to use spamsong's Viking, but didn't know
> Eric had one, too. Or maybe Eric grew its viking later. Or even worse, both
> spamsong and Eric had vikings, but the on in Eric wasn't supposed to be
> exported (like, it should have been named _Viking and someone forgot) and
> they removed it in a later release -- but you were relying on that
> undocumented misfeature. Suddenly your extended viking behaves differently,
> 'for no apparent reason'.

I haven't run into this problem (yet!) because I tend to prefix my class
names with an identifier that indicates what project, etc...the class is
from.  That is a habit from using pre-namespace Smalltalk where the was
no scoping tool for namespaces so you had to create Class names likely
not to be clobbered

Of course the return argument is that using "moduleName.ClassName" is
the correct scoping tool.

I see your points; I will rethink my approach

Thank you

-- 
Jay O'Connor
joconnor at cybermesa.com
http://www.cybermesa.com/~joconnor

"God himself plays the bass strings first when He tunes the soul"