On Wed, 17 Nov 2004, Phillip J. Eby wrote:
>
>> The __pycode__ attribute is not marshaled.
>> So for 'import'ed code, __pycode__=None
>>
>
> What good is that? Likewise, I don't see the point of having this only
> enabled when a command-line option is given.
We can marshal it if we want.
But I'm not convinced we should. Having used this system,
'import' is a good barrier to say "I'm not interested for
the __pycode__ of these". For example in the personal shell/library
were I collect nice recipies from usenet (premuttating letters
and fairy tales), I want to edit the recipe but when I import
httplib, I'm not interested in editing standard modules.
Afterall, we can execfile() in locals() to bypass import
and load a module with pycode.
>
> If the idea is just to allow saving code from interactive mode, why not just
> modify the interactive mode to do this?
>
I think that is easilly doable by the way tok_nextc() is
implemented (in 2.3.4 at least). We can avoid this if
we have sourcefile/line.
btw, don't forget the exec case:
exec """def spam():
x = 1""" in globals(), globals()
print spam.__pycode__
So having __pycode__==None can mean that
- either there is source available, and use inspect
- no source at all because we have pyc only
Another issue though is that if we implement this we
could modify inspect and drop file/lineno/linetab
and go read from __pycode__.
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