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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4