Sitelet https://web.archive.org/web/20221223110323/https://github.com/python/cpython/pull/19356
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-40169: Make dis.findlabels() accept a code object #19356

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

laike9m
Copy link
Contributor

@laike9m laike9m commented Apr 4, 2020 •

https://bugs.python.org/issue40169

Reasoning:

  • The documentation of dis has always been "it accepts a code object".
  • To keep it consistent with the other APIs in the dis module, which all accept a code object instead of raw byte code string.

@laike9m
Copy link
Contributor Author

laike9m commented Apr 7, 2020

Kindly ping...@serhiy-storchaka

Copy link
Contributor

@remilapeyre remilapeyre left a comment

Hi @laike9m, thinks for improving dis! I don't think this is the correct change thought, dis.findlabels(f.__code__.co_code) used to work but does not anymore. I think a more appropriate change would be to handle both code object and byte code, a way would be:

    if hasattr(code, 'co_code'):
        code = code.co_code
    elif not isinstance(code, bytes):
        raise TypeError(...)

A test with jumpy.__code__.co_code would be great too!

@laike9m
Copy link
Contributor Author

laike9m commented Jun 9, 2020

Thanks Remi.

I know the function was intended to take a code object because the doc explicitly says that before I fixed it to match the current behavior.
77c623b

I can change the code as you suggested. Do I need to get @serhiy-storchaka's approve before making the change? Cause I assume he owns this part.

@remilapeyre
Copy link
Contributor

remilapeyre commented Jun 9, 2020

I know the function was intended to take a code object because the doc explicitly says that before I fixed it to match the current behavior.
77c623b

Yes, but since it used to take bytes (even thought it was not documented that way) it means that users wrote code that way and they expect it to keep working. Breaking that would need a deprecation period.

I can change the code as you suggested. Do I need to get @serhiy-storchaka's approve before making the change? Cause I assume he owns this part.

As you wish, you will need his approval either way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants