This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gwk
Recipients Mark.Shannon, docs@python, gwk
Date 2021-08-09.22:33:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1628548428.41.0.569263847778.issue44875@roundup.psfhosted.org>
In-reply-to
Content
`dis.findlinestarts()` has been changed to use the no `co_lines()` function. (Blame indicates commit 877df851c3e by Mark Shannon.) However the docs currently state that it uses the older `co_firstlineno` and `co_lnotab`: https://docs.python.org/3.10/library/dis.html#dis.findlinestarts.

My cursory understanding of `dis.py` internals is that `get_instructions` relies on `findlinestarts`, implying that both of these APIs are going to return different line numbers than they did previously. I am perfectly fine with this, and hopeful that the PEP 626 changes will improve tool accuracy.

At minimum the `dis` docs should be updated. I also suggest that some kind of note about this be added to the PEP 626 text, because the way it reads now suggests that it avoids breakage by creating the new `co_lines` API. However it seems that users of the higher level dis APIs are going to see subtly different behavior.

FWIW I am fine with the change, and I hope this doesn't instigate a reversion to the old behavior. `lnotabs` semantics were very cryptic and seemed rather broken when I attempted to use it years ago. I am revisiting an experimental code coverage tool in part because of the PEP.
History
Date User Action Args
2021-08-09 22:33:48gwksetrecipients: + gwk, docs@python, Mark.Shannon
2021-08-09 22:33:48gwksetmessageid: <1628548428.41.0.569263847778.issue44875@roundup.psfhosted.org>
2021-08-09 22:33:48gwklinkissue44875 messages
2021-08-09 22:33:47gwkcreate