[Tim, still worried about stomping on unintended classes/defs] [example abusing Tkinter.Misc] > For a second I thought you got me there! That's twice as long as I thought you'd think that, so I win after all <wink>. > Fortunately, there's magic available: recently, all classes > have a __module__ attribute that is set to the full name > of the module that defined it (its key in __sys__.modules). > > For functions, we would have to invent something similar. OK! I didn't know about class.__module__ -- I hope you realize that relying on your time machine is making you lazy <wink>. I remain uncomfortable with automagic updating, but not as much so. Both kinds of errors still seem possible to me: 1. Automagically updating when it wasn't wanted. Examples of this are getting harder to come by <wink>. Off the top of my head I'm reduced to stuff like this: >>> adders = [] >>> for i in range(10): def adder(y, x=i): return y+x adders.append(adder) >>> adders[2](40) 42 >>> adders[9](33) 42 >>> "That kind of thing" has got to be rare, but can't be non-existent either (well, isn't -- I've done it). 2. Failing to automagically update when it was wanted. Implicit in the discussion so far is that long-running systems want to update code at a granularity no finer than module level. Is that realistic? I'm unsure. It's certainly easy to *imagine* the app running an updater server thread, accepting new source for functions and classes, and offering to compile and install the objects. Under the explicit new.update scheme, such a service needn't bother clients with communicating the full name of the original module; heck, in a *truly* long-running app, over time the source tree will change, and classes and functions will migrate across modules. That will be a problem for the explicit scheme too (how does it know *which* "class Misc" to update) -- but at least it's an explicit problem then, and not a "mysterous failure" of hidden magic. I could live with both of those (#1 is more worrisome); but think it easier all around to give the users some tools and tell them to solve the problems however they see fit. or-maybe-we-already-agreed-about-that-ly y'rs - tim
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