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 gvanrossum
Recipients Mark.Shannon, dom1310df, gvanrossum, vstinner
Date 2022-04-03.18:28:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1649010522.35.0.534344479216.issue47185@roundup.psfhosted.org>
In-reply-to
Content
[Victor]
> Do you consider that .replace() must reject changing co_code if other tables are not updated?

I simply don't believe it can always do that correctly, so I believe it should not do it.

> Debugging tables are not strictly required just to *execute* code, no?

No, but if they are wrong crashes might happen when they are consulted. At the very least they would confuse users.

> If you consider that the caller *must* update co_exceptiontable, replace() must raise an exception in this case, to prevent creating a code object which would behave in a strange way (broken exception handling).

No. There are a zillion use cases. If you are using .replace() you are taking responsibility for the result.

> If someone really wants testing an empty exception table just for fun, it would still be possible to pass co_exceptiontable=b''.

> My concern is more about people upgrading to Python 3.11 and who "suddenly" don't get their exceptions handled anymore. I would prefer catching such bug at the replace() call, rather than having to execute the code (and only notice the bug in production? oops).

Where would these people get the value that they're using to replace co_code? Surely if they are generating bytecode it will already be broken. Pretty much all instructions are different in 3.11.
History
Date User Action Args
2022-04-03 18:28:42gvanrossumsetrecipients: + gvanrossum, vstinner, Mark.Shannon, dom1310df
2022-04-03 18:28:42gvanrossumsetmessageid: <1649010522.35.0.534344479216.issue47185@roundup.psfhosted.org>
2022-04-03 18:28:42gvanrossumlinkissue47185 messages
2022-04-03 18:28:42gvanrossumcreate