[Python-Dev] New and Improved Import Hooks

Just van Rossum just@letterror.com
Tue, 3 Dec 2002 10:16:31 +0100


Martin v. L=F6wis wrote:

> It is very hard to read, as a patch, yes, and it does a lot of things
> that aren't clearly needed.
>=20
> However, in all cases I've investigated, the resulting import.c works
> just as fine as the original one. Don't read the patch, read the
> resulting code instead.

And then it still does many things that "aren't clearly needed".

> I don't like to reject the patch on grounds of "it is too
> complicated". Perhaps the complexity is inherent, and it can't be done
> trivially.

The complexity is inherent *because* there's no import hook mechanism tha=
t's
even remotely usable from C. My patch changes that.

> In that case, it would be a pity since it means that we can
> never get zipfile imports.

No it doesn't. It just means that a little more work is needed.

> The feature that this patch provides is well-defined. If somebody
> volunteers to cleanup the implementation later - this would be
> definitely appreciated.

It doesn't *belong* in import.c. It's bloat.

> > > In what time frame would you expect to implement the zipfile import
> > > patch using your framework?
> >=20
> > Don't know, I can't do it by myself. Shouldn't be too hard, though.
>=20
> That, of course, speaks against the framework, or atleast against
> rejecting the zipfile patch.

I rather meant "I prefer not to do it by myself".

> It seems that the likeliness is high that we get a new framework, and
> no application for it. If we require zipfile importing to use the new
> framework, we will never get zipfile importing.

Bull.

> This doesn't sound very promising, so I'd mandate that any new
> framework demonstrates its usefulness in a non-trivial case, which is
> best done by implementing (or re-implementing) zipfile import.

...

Just