[Python-Dev] __pycode__ extension

[Samuele Pedroni]

Phillip J. Eby wrote:

> At 02:24 PM 11/17/04 +0200, Stelios Xanthakis wrote:
> 
>>       #!/usr/bin/python -P
>>       def save_world():
>>           F = open ('MYSYSTEM.py')
>>           F.write ('#!/usr/bin/python -P\n')
>>           for i in globals():
>>               if hasattr (eval(a), '__pycode__'):
>>                   F.write (eval(a).__pycode__)
> 
> 
> There are bugs in this code.  First, the wrong variable is used for 
> eval(), and second, it shouldn't use eval.  If there's a global named 
> 'F', for example, the code above will not save it, because it will see 
> the local 'F' instead.  Loop over globals().values(), and do not use eval.
> 
> 
>> The __pycode__ attribute is not marshaled.
>> The logic behind this is that if we edit a function/class
>> and save it in a .pyc file, the next time the .py module
>> is executed it will overwrite the .pyc file and our changes
>> are lost.
>> So for 'import'ed code, __pycode__=None
>>
>> Hm?
> 
> 
> What good is that?


I agree with the spirit of the observation, but I think that aspect is 
immaterial. Personally I think some form of this feature is valuable as 
long as it means getting inspect.getsource (and companions) or some 
variation working no matter what. So as long as what goes in the 
attribute covers the cases not working today, that should be fine.

>  Likewise, I don't see the point of having this only 
> enabled when a command-line option is given.

well, I think some people may bring memory consumption considerations to 
the table depending of what the final implementation is. For embedding 
scenarios I suspect that a build time define could be ok.

But I think we should rember that some people today rely on the fact 
that shipping only pycs files means not shipping directly the source.