[Python-Dev] New universal import mechanism ( Re: [Python-checkins] python/dist/src/Python import.c,2.210,2.211) (original) (raw)

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 importallfrom() 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): mergeonemultimethod(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.