[Jim Fulton]
>> It [reload] also doesn't handle global data properly.
>> It tries to do something that Python modules were never designed to
>> support, which is to load them more than once.

[Shane Hathaway]
> However, given the existence of the reload() builtin, someone apparently
> believed Python modules *were* designed to support reloading.

It was certainly hopeful -- other hopeful failures include the whole
rexec/bastion maze, and the "multiple interpreters" gimmick in the C API
that some people still spend their lives trying to out-guess <0.9 wink>.

One thing they have in common is that nobody volunteered ongoing work on
them, apart from Guido, and they would have required major work to become

> Because reload() is a builtin, Python seems to promise that reload() is
> reliable, but in fact it's rarely reliable.

There are more words about reload() in the manual than about any other
builtin, and they point out problem after problem.  It's very hard to remove
a builtin (has it ever been done?  I don't recall a case -- although apply()
is silently "deprecated"), and reload() was there from the start.  I thought
it was a bad sign when Python NEWS for version 1.0.2 remarked that there
were now "fewer chances of dumping core when trying to reload ..." <wink>.

> There would be a lot less confusion if reload() were moved somewhere like
> the "imp" module.

It's slated to disappear from Python 3000:


I doubt it will be removed from __builtin__ before then.

>> When it fails, it does so in subtle ways that cause people to lose lots
>> of time.

> I agree.  The right way to refresh is to detect code changes (ideally
> using Linux's brand new inotify mechanism, or something similar when
> inotify is not available), display a "please wait" message to the user,
> and restart the process.

If you're changing more than one file, how could that know when the source
code is in a globally consistent state again?  (BTW, there are efficient
ways to get notifications about modified files even on Win95, so that part
isn't a hangup.)

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to