Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Chris Angelico <rosuav@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: Reason for not allowing import twice but allowing reload()
Date: Wed, 2 Mar 2016 05:04:39 +1100
Lines: 59
Message-ID: <mailman.74.1456855482.20602.python-list@python.org>
References: <645cdd46-d4a4-49b3-a0d8-848608d70d73@googlegroups.com> <mailman.8.1456729298.2321.python-list@python.org> <56d57aa4$0$1586$c3e8da3$5496439d@news.astraweb.com> <mailman.61.1456832379.20602.python-list@python.org> <56d5cd36$0$22142$c3e8da3$5496439d@news.astraweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
In-Reply-To: <56d5cd36$0$22142$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Xref: csiph.com comp.lang.python:103808

On Wed, Mar 2, 2016 at 4:11 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Tue, 1 Mar 2016 10:39 pm, Chris Angelico wrote:
>
>> On Tue, Mar 1, 2016 at 10:18 PM, Steven D'Aprano <steve@pearwood.info>
>> wrote:
>>> I cannot imagine why you would want to reload() in production code. That
>>> would imply that your production code is modifying already-imported
>>> modules, then wanting to import them again. Why would anyone in their
>>> right mind do that? Possibly because they lost a bet?
>>
>> BartC and I have both done this exact thing, though neither of us used
>> Python for it. It's not so insane as you might think; sometimes you
>> want to update code, but you don't want to restart a process. Just
>> because you've never had a process that hits a year of uptime doesn't
>> mean nobody else does. :)
>
> I've had an uptime of over 400 days on my laptop, without logging out, so
> yes I have had processes with over a year of uptime. But that doesn't mean
> I expect to modify the code of a running process and reload it. Modify
> data, sure, but not code.
>
> I'll grudgingly accept that, just maybe, if you have some sort of plugin
> system, you may want to unload and reload plugins, replacing the old plugin
> with a new one of the same name. Maybe you could get that to work in Python
> using the import system.

And then you expand the plugin system so it includes everything other
than a kernel that manages plugins, and you now have the kind of
system I'm talking about. My MUD server and client are both structured
like this:

1) Startup file, which does basic setup, initializes all other files,
then (in the server) binds to a port and starts listening. It then
drops to a back-end loop, either threaded or async I/O.
2) Globally-available utilities toolbox. Can be reloaded to add or
edit any of the functions/classes in it.
3) (Client only) GUI handling file. Creates the window, handles user
interaction. Can be reloaded, although since it doesn't destroy and
recreate the window, some changes won't take effect until full
restart.
4) All other plugins, which can do pretty much anything. The system is
quite happy to add, remove, and update these at any time.

Everything except the startup file can be edited after startup. That's
basically _every_ piece of code in the whole project. Major features
can be implemented and debugged without resetting anything, and once
I'm satisfied with the code, I commit and push, and end users can pull
that change without restarting.

If I were to implement this in Python, I would probably do it by
reimplementing module-like behaviour, rather than actually using
import. But it could be made to work, and it definitely has its
benefits. On the server, it's crucial - I can't kick my users off
every time I make changes; even on the client, having to restart and
reconnect for every change would be tedious, although that's more for
my own debugging than for other people's usage (it's not as big a deal
to update the program once a week and then have to restart).

ChrisA