> > This is a fallacy, because the user still has to order the cleanup by > > using the correct decorator. We can't afford to decorate *every* > > function with this mechanism (method calls are already too expensive). > > My impression is that if integrated into the interpreter core, this > wouldn't be particularly expensive. Fundamentally, it would look > something like this: > > class C(RAII): > def __init__(self): > RAII.register(self) > > def foo(): > x = C() > > then somewhere in the guts of the function calling mechanism, just > before the scope unwinding, we'd have: > > for o in registered_objects: > o.__finalize__() > > This is IMO an attractive nuisance, but I don't think it imposes much > burden in execution speed. I do see the attraction as being similar to > that of metaclasses and decorators: power provided to the end-developer > with few demands for understanding. So you propose to add a list of registered objects to each stack frame, and to add code to look at that list upon function return. YOu betcha that that is going to slow down short function calls -- if only by a few instructions, it's still a trend in the wrong direction. --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