[Python-Dev] New universal import mechanism ( Re: [Python-checkins] python/dist/src/Python import.c,2.210,2.211)
Samuele Pedroni
pedronis@bluewin.ch
Tue, 3 Dec 2002 15:24:59 +0100
----- Original Message -----
From: "Jeff Epler" <jepler@unpythonic.net>
To: <python-dev@python.org>
Sent: Tuesday, December 03, 2002 3:24 PM
Subject: Re: [Python-Dev] New universal import mechanism ( Re:
[Python-checkins] python/dist/src/Python import.c,2.210,2.211)
> On Tue, Dec 03, 2002 at 03:59:05AM -0500, Guido van Rossum wrote:
> > Alas, the current import hooking mechanisms don't allow control over
> > this (the interpretation of * is hardcoded). Feel free to suggest an
> > API and/or implementation of a hook for that, after reading how it's
> > done now. The crucial code is import_all_from() in ceval.c.
>
> Currently __all__ is a list of all the attributes to be exported by the
> module. What if we let __all__ be a list (with its current
> interpretation) or a callable.
>
> If __all__ is callable, then it is called with two parameters: the
> importing module, and the imported module. It can perform the desired
> operation. Any returned value is ignored, any raised exception is
> propagated.
>
> In David Abraham's case, the hook might look something like this:
>
> def __all__(exporter, importer):
> for name, attr in vars(exporter).items():
> if name.startswith('_'): continue
> if isinstance(attr, Multimethod):
> merge_one_multimethod(importer, name, attr)
> else:
> setattr(importer, name, method)
>
> (David, apologies if I've simplified this too much. All I know about
> your desired functionality is that you want to "merge multimethods", and
> I have some idea what a multimethod is..)
>
I find this idea of a semantics change rather unpythonic;
( 2nd in general should not import * be avoided ?)
Why then only import * should have a user-defined behavior?
What about
from module import x
if the importing module has already a defined x then maybe that should be also
under user control?
I'm surely missing something.
regards.