I like the proposal in general but I am against removing lnotab. The reason is that many tools rely on reading this attribute to figure out the Python call stack information. For instance, many sampler profilers read this memory by using ptrace or process_vm_readv and they cannot execute any code on the process under tracing as that would be a security issue. If we remove a 'static' view of that information, it will impact negatively the current set of remote process analysis tools. The proposed new way of retrieving the line number will rely (if we deprecate and remove lnotab) on executing code, making it much more difficult for the ecosystem of profilers and remote process analysis tools to do their job.
+1 agreed.
This breaks existing tooling.
"The co_linetable attribute will hold the line number information. The format is opaque, unspecified and may be changed without notice."
...
"Tools that parse the co_lnotab table should move to using the new co_lines() method as soon as is practical."
Given it is impossible for tools doing passive inspection of Python VM instances to execute code, co_linetable's exact format will be depended on just as co_lnotab was. co_lnotab was only quasi-"officially" documented in the Python docs, it's spec lives in
https://github.com/python/cpython/blob/master/Objects/lnotab_notes.txt (pointed to by a couple module's docs). The lnotab format "changed" once, in 3.6, an unsigned delta was changed to signed (but I don't believe anything beyond some experiments ever actually used negatives?).
How about creating something defined and always present for once given the need has been demonstrated. Even if we don't, it will be used, and we will be unable to change it within a release.
-gps