M.-A. Lemburg wrote: > While it seems like a nice idea to update code which is already in > use, I think that this leads down the wrong track. Sooner or > later you'll end up with a complete mess in memory ;-) And depending > on what code you exchange, this can cause serious problems: e.g. > pickled data could become unusable, parts of the system would > suddenly stop working because of e.g. a name change in one of the APIs, > etc. I don't see "enhanced reloading" as a way to modify long running processes, but a way to shorten the development cycle. Sure, things can break, but that happens while you're coding, right? ;-) The worst thing that can happen is that you have to restart your app. > > General question: why if func_globals not a writable attribute? > > Why should it be ? Just think of the security holes this would > open. Huh? You can change func_globals in place, I don't see how it's more vulnerable to replace it with another dict. Assigning to func_code, func_defaults, func_doc and func_dict is allowed, I was just wondering if there's a specific reason why it's not allowed for func_globals. Am I missing something obvious here? Just
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