[Python-Dev] new import hooks & zip import

[Just van Rossum]

Guido van Rossum wrote:

> Hm, I'd prefer None. 

The reason I prefer an exception (any exception, could be a new one) is that you
can't return None from an __init__ method, and a class/type is the *perfect*
candidate for a hook (zipimport.zipimporter is one, too). I'd prefer it if
people didn't have to write a __new__ method or a separate factory function.

> With an exception (especially when you're
> reusing an existing exception) you never know if it was raised
> intentionally or whether it means a real (unexpected) error -- in the
> latter case, swallowing the traceback would be a bad idea because it
> makes diagnosing the real problem hard.  ("Why does my zipimport not
> work?  I don't get any errors, but it doesn't work...")

(I think import.c should print a warning if the zipimport hook couldn't be
installed, similar to the site.py warning. The hook itself doesn't invoke any
Python code, so an ImportError is a 100% sure sign zipimporter can't handle the
path.)

Unless you do imports *in* the function/class __init__ that is the hook, there's
no chance of getting ImportErrors after the hook is installed, so I'm not too
worried.

The problem is perhaps comparable to old-style sequence iteration: the
__getitem__ implementation *could* raise a different IndexError than the author
intended.

Just