I don't recall anyone reacting to this idea from Alex Hall. As he mentioned, IPython implements its own way of caching code entered in the REPL. IDLE does as well and uses it when providing traceback. Recently (starting with Python 3.10.0a5), IDLE started exposing such cached content so that custom excepthooks could make use of it (which I find very useful for one of my own projects and was actually asked by one of IDLE's maintainers to test this new IDLE feature). Such a proposal would be completely backward compatible and would be useful for many third-party packages including those mentioned by Alex Hall in the post quoted below. André Roberge On Sat, Jan 2, 2021 at 10:29 AM Alex Hall <alex.mojaki@gmail.com> wrote:
When using `exec(string)`, the standard Python REPL, or `python -c` in a terminal, the executed source code is not stored anywhere and cannot be retrieved (except in the `-c` case by looking at `sys.argv`). This means that:
- The source line doesn't show up in tracebacks, e.g:
>>> exec("1/0") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<string>", line 1, in <module> ZeroDivisionError: division by zero
- Users cannot retrieve the source code using `inspect`, although many want to: - https://stackoverflow.com/questions/29850508/python-how-to-inspect-code-of-f... - https://stackoverflow.com/questions/12072252/cant-get-source-code-for-a-meth... - https://stackoverflow.com/questions/62160529/how-to-get-source-inside-exec-p... - https://stackoverflow.com/questions/59244323/how-can-you-get-the-source-code... - https://stackoverflow.com/questions/50822656/source-code-for-an-evaled-dynam... - https://stackoverflow.com/questions/50515651/why-does-the-python-linecache-a... - Libraries such as traceback formatters and debuggers which depend on source code can't work. This often manifests when people try out a library for the first time in the REPL and it doesn't seem to work. This leads to many similar looking bug reports which sometimes take a while to resolve. Probably many more people think these libraries don't work without ever opening an issue. - https://github.com/cknd/stackprinter/issues/34 - https://github.com/Qix-/better-exceptions/issues/17 - https://github.com/Qix-/better-exceptions/issues/68 - https://github.com/aroberge/friendly-traceback/issues/23 - https://github.com/gruns/icecream/issues/17 - https://github.com/cool-RR/PySnooper/issues/135 - https://github.com/cool-RR/PySnooper/issues/164 - https://github.com/alexmojaki/sorcery/issues/3 - https://github.com/alexmojaki/sorcery/issues/5 - https://github.com/alexmojaki/sorcery/issues/6
I suggest that:
1. `exec(string)` assigns a unique generated filename to the compiled code object and stores the source code in the `linecache` module under that filename, similar to what the IPython REPL does. I imagine there might be complaints about memory usage, security implications of revealing source code, compatibility, etc. If that's an issue this could be off by default with a flag to turn it on. 2. The REPL, `-c`, and other similar mechanisms (IDLE?) either follow the same strategy as `exec` or defer to it. 3. The standard exception hook falls back to `linecache` for filenames that don't exist. I don't know why it doesn't already. Here is a question on that topic: https://stackoverflow.com/questions/50515651/why-does-the-python-linecache-a... _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CMM5ZV... Code of Conduct: http://python.org/psf/codeofconduct/