Phillip J. Eby wrote: > At 06:49 AM 11/18/04 +0200, Stelios Xanthakis wrote: > > I think it's important to clarify what this is *for*, and then address > whatever that use case is directly. So far, lots of people are > projecting their own use cases onto it, and therefore we all disagree on > what the best way to implement it is. True - hopefully a PEP can flush out most of the use cases. >> Having used this system, >> 'import' is a good barrier to say "I'm not interested for >> the __pycode__ of these". > > > Having used it for whatever purposes *you're* using it for. Evidently > you want to use it for something very different from what I would want > it for (source code transforms, such as AOP "advice" injection). The interface I envisioned with my last message was something like: exec compile(source_str, source_file, 'exec', compile.STORE_SOURCE) However, I've now discovered that the flags argument to compile is currently used only for controlling which __future__ statements are in effect. So this would be a significant change, as it would using a portion of the __future__ machinery to control something that is never intended to become default behaviour. With this approach (or something similar, like a separate 'store=compile.SOURCE' argument to compile instead of piggybacking the future machinery), normal code remains unaffected, but an application can enable the functionality when it wants it by compiling the source code directly with the option enabled. It may be reasonable to alter the interactive shell to enable the option for code entered at the interactive prompt. This way, code compiled normally does not get its source stored in memory or the pyc files. Code which needs the source to operate correctly can be compiled with the option, and the relevant parts of the source would then be stored With the ast-branch in, similar functionality could be provided for 'compile.STORE_AST' or 'store=compile.AST' (OR the flags to store both source and AST). At-least-we-don't-have-to-worry-about-getting-enough-material-for-a-PEP'ly, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan at email.com | Mobile: +61 409 573 268
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