[Import-sig] Re: Proposal for a modified import mechanism.

[M.-A. Lemburg]

Michel Pelletier wrote:
> 
> "Barry A. Warsaw" wrote:
> >
> > Are the needs of application authors different than library authors?
> 
> This is the best place to start, almost everyone on this list plays both
> roles to one degree or another.  I've read Prabhu's emails and I
> understand his problem.  He's explained it a couple of times, but in
> general users and their needs have been unclear which I think spawned
> most of this discussion.

Well, I've been there and done that. I also proposed an (implicit) 
relative import scheme some years ago, because I thought it might be
worthwhile having to sort out the problems with naming conflicts,
local installs etc.

In the meantime I found that I can work well without
relative imports by being careful about the import statements
I use in software using the packages and in modules of the packages
themselves.

IMHO, it's a much better strategy to think about defining a
proper absolute package name structure and using it throughout
your code. Given such a structure, the need for relative imports
which are hard to debug and can cause a whole variety of
problems (e.g. pickled objects still carry the absolute package
name, modules can be overridden without the user realizing this,
etc.).
 
> I'm actually sort of interested in more about the idea of 'looking up'
> for packages that Prabhu mentioned and think it could be very useful.
> In Zope we call this "acquisition" and we use this pattern many, many
> times to override general site  policies and objects with more specific
> ones the farther "down" you go in the object heirarchy.  This not only
> gives us a nice customization model, but it also gives us a nice
> delegation model, ie, those responsible on high (that's all of you) can
> dictate what is and is not the standard library "policy" and users below
> you (that's me and all the other lusers) can specificly override that
> mandate at a lower level without interfering with other users.

Then you probably also know that debugging an acqusition scenario
can become a nightmare, simple due to the fact that each and
every attribute has to be tracked to where it's defined in the
acquisition hierarchy in order to tell where the problem originated.

Acquisition is very nice if it works, but way to complicated for
causal users manage in case something goes wrong. The same
goes for relative imports which are essentially the same thing
w/r to module lookups in packages.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/