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-45168: change dis output to omit missing values rather than replacing them by their index #28313

Merged
merged 4 commits into from Sep 14, 2021

Conversation

@iritkatriel
Copy link
Member

@iritkatriel iritkatriel commented Sep 13, 2021

https://bugs.python.org/issue45168

Copy link
Member

@gvanrossum gvanrossum left a comment

Is there no way to just not display the parenthetical comment at all?

@iritkatriel
Copy link
Member Author

@iritkatriel iritkatriel commented Sep 13, 2021

Is there no way to just not display the parenthetical comment at all?

Yes, I can make get* functions return a "no value" sentinel that gets ignored later.

Though I just noticed that all this is documented, so unless we are willing to change the documented API, even what I did here is no good (we'd need to add another field to Instrcution which can be set to what we want to display): https://docs.python.org/3/library/dis.html#dis.Instruction

@gvanrossum
Copy link
Member

@gvanrossum gvanrossum commented Sep 13, 2021

I think we can change that API, at the top of that page I see this:

CPython implementation detail: Bytecode is an implementation detail of the CPython interpreter. No guarantees are made that bytecode will not be added, removed, or changed between versions of Python. Use of this module should not be considered to work across Python VMs or Python releases.

@iritkatriel iritkatriel changed the title bpo-45168: change dis output to be '-' for missing values rather than… bpo-45168: change dis output to omit missing values rather than replacing them by their index Sep 13, 2021
Copy link
Member

@gvanrossum gvanrossum left a comment

(Sorry, I think I said the same thing three times. That's what you get when I make a single pass over the review. :-)


.. data:: argrepr

human readable description of operation argument
human readable description of operation argument (if known).
Copy link
Member

@gvanrossum gvanrossum Sep 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should state what it is if not known -- you cannot rely on the "versionchanged" note for that. I wouldn't leave it unset, but I'd be okay if it was one of: None, "", "<unknown>" or dis.UNKNOWN. BTW, what is it for opcodes that don't have an oparg (like RETURN_VALUE)?

Copy link
Member Author

@iritkatriel iritkatriel Sep 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was planning to define what it is, but then I need to assert that in a unit test and it's actually not possible to create an Instruction object with an UNKNOWN argval through the public API (unless I construct it directly, but then what am I actually checking?). You can generate them by calling get_instruments get_instructions, but that only works for things that do have co_consts and co_names (you can't give it just the bytes of the code).

Copy link
Member Author

@iritkatriel iritkatriel Sep 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

get_instruments --> get_instructions (typing instrument is muscle memory you get from working in a bank. I did it several times today)

Copy link
Member Author

@iritkatriel iritkatriel Sep 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we don't need to document the "unknown value" case at all here, since it's an internal thing of the dis module?

Copy link
Member Author

@iritkatriel iritkatriel Sep 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, what is it for opcodes that don't have an oparg (like RETURN_VALUE)?

It's an empty string.

Lib/dis.py Outdated
@@ -283,7 +290,7 @@ def _disassemble(self, lineno_width=3, mark_as_current=False, offset_width=4):
if self.arg is not None:
fields.append(repr(self.arg).rjust(_OPARG_WIDTH))
# Column: Opcode argument details
if self.argrepr:
if self.argrepr and self.argval is not UNKNOWN:
Copy link
Member

@gvanrossum gvanrossum Sep 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This suggests that if argval is UNKNOWN, we could set argrepr to None or an empty string, rather than testing argval?

Copy link
Member Author

@iritkatriel iritkatriel Sep 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could set it to empty string. I didn't want to make it None because now it's always a string.

if get_name is not None:
argval = get_name(name_index, **extrainfo)
argrepr = argval
return argval, argval
Copy link
Member

@gvanrossum gvanrossum Sep 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So here I had expected argval, None or argval, "".

Copy link
Member Author

@iritkatriel iritkatriel Sep 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the case where argval can be calculated, and since it's a name it's equal to its repr so we don't do repr(argval) for the second item.

Copy link
Member

@gvanrossum gvanrossum left a comment

Nice.


.. data:: argrepr

human readable description of operation argument (if known).
human readable description of operation argument (if any),
Copy link
Member

@gvanrossum gvanrossum Sep 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like how you kept it ambiguous whether "if any" refers to the argument or to the description. :-)

@iritkatriel iritkatriel merged commit c99fc4e into python:main Sep 14, 2021
12 checks passed
@iritkatriel iritkatriel deleted the bpo-45168 branch Nov 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants