[Python-Dev] __pycode__ extension

[Nick Coghlan]

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