On Wed, Mar 2, 2016 at 4:11 AM, Steven D'Aprano <st...@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 <st...@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 -- https://mail.python.org/mailman/listinfo/python-list
