> From: "Tim Peters" <tim_one@email.msn.com> > > [Guido, on Andrew's idea for automagically updating > classes] > > > There might be another solution. When you reload a module, > > the module object and its dictionary are reused. > > > > Perhaps class and function objects could similarly be > > reused? It would mean that a class or def statement > > looks for an existing object with the same name and type, > > and overwrites that. Voila, all references are > > automatically updated. > > Too dangerous, I think. While uncommon in general, I've certainly seen > (even written) functions that e.g. return a contained def or class. The > intent in such cases is very much to create distinct defs or classes > (despite having the same names). In this case I assume "the same name" > wouldn't *usually* be found, since the "contained def or class"'s name is > local to the containing function. But if there ever happened to be a > module-level function or class of the same name, brrrr. Agreed that that would be bad. But I wouldn't search outer scopes -- I would only look for a class/def that I was about to stomp on. > Modules differ because their namespace "search path" consists solely of the > more-global-than-global <wink> sys.modules. "The search path doesn't enter into it." > > This is more work (e.g. for classes, a new bytecode may > > have to be invented because the class creation process > > must be done differently) but it's much less of a hack, > > and I think it would be more reliable. (Even though it > > alters borderline semantics a bit.) > > How about an explicit function in the "new" module, > > new.update(class_or_def_old, class_or_def_new) > > which overwrites old's guts with new's guts (in analogy with dict.update)? > Then no semantics change and you don't need new bytecodes. Only a slight semantics change (which my full proposal would require too): function objects would become mutable -- their func_code, func_defaults, func_doc and func_globals fields (and, why not, func_name too) should be changeable. If you make all these assignable, it doesn't even have to be a privileged function. > In return, a > user who wants to e.g. replace an existing class C would need to do > > oldC = C > do whatever they do to get the new C > new.update(oldC, C) > > Building on that, a short Python loop could do the magic for every class and > function in a module; and building on *that*, a short "updating import" > function could be written in Python. View it as providing mechanism instead > of policy <0.9 wink>. That's certainly a reasonable compromise. Note that the update on a class should imply an update on its methods, right? --Guido van Rossum (home page: http://www.python.org/~guido/)
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