A RetroSearch Logo

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

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2001-December/019012.html below:

[Python-Dev] regrtest.py mystery

[Python-Dev] regrtest.py mysteryKa-Ping Yee ping@lfw.org
Mon, 17 Dec 2001 15:05:12 -0600 (CST)
On Mon, 17 Dec 2001, Tim Peters wrote:
> "A fix" seems to amount to treating
>
> import M
>
> as if it were
>
> try:
>     import M
> except:
>     if M in sys.modules:
>         del sys.modules[M]
>     raise

I remember suggesting exactly that some time ago (i think it was
motivated at the time by the extreme pain that broken modules were
causing for webserver-mode pydoc in its attempt to update loaded
modules if the source files had changed on disk).

Guido rejected it because you can't guarantee that the refcount on M
is 1 at the point where you attempt to 'del sys.modules[M]' above.
(For example, some other module imported by M could have imported M
again, and so hold a reference to it while M is running its startup
commands.  This is why the entry is added to sys.modules before the
body of M starts to run.)

He deemed the situation where M is loaded-but-missing-from-sys.modules
to be even worse than for M to be left loaded-but-broken therein.  If
you allow M to stay in sys.modules, then you can at least maintain the
guarantee that there is a one-to-one association between loaded module
names and loaded module objects.  If you remove M from sys.modules but
it lingers in memory, referenced elsewhere, you lose even that -- there
can be many modules loaded all with the same name and it's a nightmare.

The argument is compelling and i am forced to agree, but i still think
that we should look for a better solution.  I'll ponder this and post
any ideas i come up with.


-- ?!ng




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