|
Dustin Mitchell
dustin at ywlcs.org
Wed May 29 19:45:44 EST 2002
Sorry, meant to send this to the list.. ----- On Wed, May 29, 2002 at 03:57:38PM -0700, Ian Clelland wrote: > > 2. One other difficulty: some modules actually *do* want to have global > > state. For example, a MySQL interface should be able to establish its > > connection once and maintain that through many requests. > > But in general, you can't guarantee this in *any* situation. All of the > modules have to work properly when none of their resources are > installed (say, on server startup,) and they have to be prepared to die > at any point. > > Usually, persistent connections are used for performance reasons only; > the modules would otherwise be perfectly happy re-opening every > database connection on every hit. Right, and in a development environment (the only place one would use a reloader) I suppose that would be acceptable. However, if you're testing against the production database server (a not-unreasonable proposition for a small to midsize shop with a complex database schema), all those extra connections might prove to be a burden. And you can't guarantee that Python will close them when the module is "unloaded", as the module may continue to exist for some time. I'm sorry to be pedantic. I'm not arguing that such a feature is *required*, or necessary for any purpose (gee, don't test against your production database server!), but that it would have *some* benefits, at *minimal* cost (see below regarding cost), and is thus a win overall. > This auto-reload feature should only be used during development anyway, > so performance issues like this shouldn't be a problem (turn it off > during heavy load testing, of course), and it would be much easier than > completely restarting the web server after every source file change, > which is what I'm currently doing. > > > > Perhaps there should be a mechanism for a module to say "don't remove > > me!", or at least "preserve the value of this variable". > > I don't think this is possible in the general case (and I'm pretty sure > Python doesn't support it). What would happen if a new version of the > source file uses a different name for the variable? Or worse, uses the > same variable (name) for a completely different purpose? As to the first suggestion (a mechanism for a module to say "don't remove me!"), that is already supported in that you do not reload Python standard modules. Perhaps you could add a check for a __no_reload__ symbol or the like? Regarding permanent variables, under ordinary Python reload semantics, you can do something like: try: x = my_retained_variable del x except: my_retained_variable = initial_value but that's just for the record. I can't see why you could possibly want to do that, *particularly* in mod_python. :-) Dustin -- Dustin Mitchell dustin at ywlcs.org http://people.cs.uchicago.edu/~dustin/ ----- End forwarded message ----- -- Dustin Mitchell dustin at ywlcs.org http://people.cs.uchicago.edu/~dustin/
|