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 twouters
Recipients lukasz.langa, pablogsal, serhiy.storchaka, twouters
Date 2019-09-13.09:35:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1568367308.43.0.741143832204.issue38115@roundup.psfhosted.org>
In-reply-to
Content
Setting Py_SIZE of the bytes object is possible, but gross and not how you're supposed to operate on bytes.

I'm also not entirely convinced lnotab isn't reused in ways it shouldn't. The peephole optimizer already does gross things and is tied very intimately into the compiler and assembler structs, and any change I tried caused weird side-effects. I'm not comfortable making these changes without extensive rewrites of those bits of the code, which Mark Shannon is already working on for different reasons.

The current lnotab format doesn't really have the concept of 'no-op fillers', because zero-increment entries are used to add to previous entries. Adding the concept could mean breaking third-party consumers of lnotab. Of all the uses of lnotab that I could find, dis.findlinestarts() was the only one that didn't ignore the invalid entries. I think just documenting the current behaviour (which, just as a reminder, has been around forever, but is just more obvious in Python 3.8) and fixing dis.findlinestarts() is enough of a fix for the foreseeable future. See GH-16079.
History
Date User Action Args
2019-09-13 09:35:08twouterssetrecipients: + twouters, lukasz.langa, serhiy.storchaka, pablogsal
2019-09-13 09:35:08twouterssetmessageid: <1568367308.43.0.741143832204.issue38115@roundup.psfhosted.org>
2019-09-13 09:35:08twouterslinkissue38115 messages
2019-09-13 09:35:08twouterscreate