[Python-Dev] __pycode__ extension
pedronis at bluewin.ch
Wed Nov 17 20:37:18 CET 2004
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
> 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.
More information about the Python-Dev