On Tue, Jul 28, 2020 at 2:12 PM Jim J. Jewett <jimjjew...@gmail.com> wrote:
> 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. > Introspection of the running CPython process is happening from outside of the CPython interpreter itself. Either from a signal handler or C/C++ managed thread within the process, or (as Pablo suggested) from outside the process entirely. Calling CPython APIs is a non-option in all of those situations. That is why I suggested that the "undocumented" new co_linetable will be used instead of the disappeared co_lnotab regardless of documentation or claimed stability guarantees. It sounds like an equivalent read only data source for this purpose. It doesn't matter to anyone with such a profiler if it is claimed to be unspecified. The data is needed, and the format shouldn't change within a stable python major.minor release (we'd be unlikely to anyways even without that guarantee). Given this, I suggest at least specifying valuable properties of it such as "read only, never mutated" even if the exact format is intentionally left as implementation defined, subject to change between minor releases structure. -gps > > -jJ > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/WUEFHFTPVTOPA3EFHACDECT3ZPLGGTFJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MQHSIXLAUL2ZSRORRDJEF3I3T73XP772/ Code of Conduct: http://python.org/psf/codeofconduct/
