Phillip J. Eby wrote:
>
>> OTOH I personally fully appreciate why you may want to have it work
>> even if just pycs are around.
>
>
> For me, a half-working __source__ feature is almost worse than none at
> all, since the former could lead to the illusion of making progress
> towards code reflection. This is why I'd like it made clearer what
> problems this is and is not meant to solve, so that programmers who are
> tempted to use the feature will be clearer as to what is and isn't a
> good idea to do with it.
>
well, personally I think an inspect.getsource that is working and
correct as much as possible is a worthy goal. Or a new getast.
At this point I see these possible levels of implementation/functionality:
0) disabled
1) attach source only to exec-ed/eval-ed code
(with this level inspect.getsource would still do the wrong thing
in the case for example of editing)
2) try to always attach source code, don't store it in pyc files,
for correct behavior a likely approach is to read pyc and py files
in parallel
3) always attach source code, store source in some form in the pyc files
I repeat that other means can be devised than flavor 1 of
implementation, to distinguish exec-ed/eval-ed/interactive code from
code from .py files.
Because of people with memory/disk usage considerations and people
preferring no-source shipping we may have to implement to some extent
all of 0,2,3.
Unless e.g. storing ASTs instead of source will be deemed enough safe,
or the fact that in 3 the source is not really just open-text-editor
away (I doubt that).
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