Fernando Perez: > Well, not necessarily pushback, but I'd like a clarification at least. > What kind of memory overhead does this introduce? If every function > running around is holding a full copy of all its source, is this > overhead potentially significant? The overhead I'm worried about is the performance cost in the parser. The memory doesn't worry me because computer's memory gets more every year while python source remains compact. It's the debate of maintanability vs optimization. > What happens with decorators, which modify functions but are > not explicit source-level transformations? I don't know about that. I guess decorator declarations are included in the source of a function. > Since this is already fairly straightforward to implement via inspect, > I'd like to see a pretty strong justification for its real need before > seeing it go in. 'inspect' can't keep the source of functions defined with 'exec' or interactively (or can it?). Moreover, you can edit a function at runtime and see it with inspect. As I stated in the OP at c.l.p, this all can be done in python as it is, by using some framework (Zope, whatever). In fact I started from such a framework but then it occured to me that it's the job of the parser to do this. In other words, with __pycode__ python becomes a framework. But I'm not here to sell amway products:) When/if pythoneers decide they like it, let me know. Regards, Stelios
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