[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