> Guido wrote:
>
> > > Skip Montanaro wrote:
> > >
> > > > Scanning the patch summary I see:
> > > >
> > > > sys.path_hooks is a list of callable objects that take
> > > > a string as their only argument. A hook will be called
> > > > with a sys.path or pkg.__path__ item. It should return
> > > > an "importer" object (see below), or raise ImportError
> > > > or return None if it can't deal with the path item. By
> > > > default, sys.path_hooks only contains the zipimporter
> > > > type, if the zipimport module is available.
> > > >
> > > > Why have it raise ImportError or return None if it can't
> > > > deal with the path item? Shouldn't there be only one way to
> > > > report failure? (Or do I misread your explanation?)
> > >
> > > No, you read correctly... I'm not sure, I just thought if
> > > might be convenient to also be able to return None. I'd
> > > be happy to stick with just one way, though (which would
> > > be raising ImportError, as that's easiest from __init__
> > > methods).
> >
> > Hm, I'd prefer None. 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...")
[Paul Moore]
> The problem is that in 99% of cases (and specifically for
> zipimporter) the "callable object" in question is a class. It's
> not possible for a class when called to return a value (the
> constructor either does its job or raises an exception). So an
> exception signalling "I don't apply to this path item" is the
> only way of letting classes be put directly on sys.path_hooks.
> You could mandate wrappers, but I imagine that
>
> def my_importer_wrapper(path):
> try:
> return my_importer(path)
> except ImportError:
> return None
>
> sys.path_hooks.append(my_importer_wrapper)
>
> is even more offensive...
>
> Actually, I'd say that "I can't handle this" should *always* be
> signalled by an exception (Only One Way To Do It), but rather than
> reusing ImportError, that should be a new exception type (I don't
> know what to call it though - ImportHandlerError?) That way, you
> don't risk masking real exceptions.
OK, point taken.
--Guido van Rossum (home page: http://www.python.org/~guido/)
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