ah... we may have been talking past each other.
Steve Dower wrote:
On 25Jul2020 2014, Jim J. Jewett wrote:
But it sounds as though you are saying the benefit
[of storing the line numbers in an external table, I thought, but perhaps Pablo Galindo Salgado and yourself were talking only of the switch from an lnotab string to an opaque co_linetable?]
is irrelevant; it is just inherently too expensive to ask programs that are already dealing with internals and trying to optimize performance to make a mechanical change from: code.magic_attrname to: magicdict[code] What have I missed?
You've missed that debugging and profiling tools that operate purely on native memory can't execute Python code, so the "magic" has to be easily representable in C such that it can be copied into whichever language is being used (whether it's C, C++, C#, Rust, or something else).
Unless you really were talking only of the switch to co_linetable, I'm still missing the problem. To me, it still looks like a call to:
PyAPI_FUNC(PyObject *) PyObject_GetAttrString(PyObject *, const char *);
with the code object being stepped through and "co_lnotab" would be replaced by:
PyAPI_FUNC(PyObject *) PyDict_GetItem(PyObject *mp, PyObject *key);
using that same code object as the key, but getting the dict from some well-known (yet-to-be-defined) location, such as sys.code_to_lnotab.
Mark Shannon and Carl Shapiro had seemed to object to the PEP because the new structure would make the code object longer, and making it smaller by a string does seem likely to be good. But if your real objections are to just to replacing the lnotab format with something that needs to be executed, then I apologize for misunderstanding.