RetroSearch Browse

Tue Jul 27 19:17:54 CEST 2004 · https://mail.python.org/pipermail/python-dev/2004-July/046435.html

On Tue, 27 Jul 2004 12:39:22 -0400
Jim Fulton <jim at zope.com> wrote:

> Tim Peters wrote:
> > [Jim Fulton]
> > ...
> > 
> >>No, it won't.  For example, suppose foo imports B. B tries to import
> >>C, but fails.  B is now broken, but it is still importable. 
> >Actually,>both foo and B can be imported without errors, even though
> >they are>broken.
> > 
> > 
> > Then you're proposing a way for a highly knowledgable user to
> > anticipate, and partially worm around,  that Python leaves behind
> > insane module objects in sys.modules. 
> 
> No.  I'm proposing a way for a Python developer to detect the
> presence or absence of a module.
> 
> Hm, perhaps it would be better to provide an API (if there isn't one
> already) to test whether a module is present.

If such an api were to exist, what question exactly would it answer?

1. That there is a module by a particular name that could possibly be
imported, but the import may not succeed when actually tried.

2. There is a module by a particular name which can be imported and the
import will not
fail.

I would vote for the former, but it might be surprising to run into
behavior like this:

>>> sys.hasmodule('foo')
True
>>> import foo
ImportError: foo blew

What if there was a new exception ModuleNotFoundError which subclassed
ImportError. This would be raised by the import machinery when the
module could not be found. Errors during import would continue to raise
a standard ImportError.

I think this, coupled with Jim's original suggestion and Tim's to
prevent broken modules being retained in os.modules would help a lot.

-Casey

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-July/046435.html below:

[Python-Dev] Re: Fix import errors to have data