GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||||||||||
GeezerVison is showing github.com — gh-149026: Add colour to `pickletools` CLI output by hugovk · Pull Request #149027 · python/cpython Conversation
|
|
Aside: the alignment is the same in # make a mild effort to align arguments ... # make a mild effort to align annotations ... If someone's up for making a bit less mild effort in another PR, go for it! |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
Can we have the instruction names in white (no color)? I find it less readable with colors as all instructions have the same color. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
IMO, too many colors hurt more than they help. White is not that good either actually... I do like the colors for literals and the first column but I feel that colors for instruction names are always too much because it's just adding colors to words that will anyway be classified identically. Alternatively, how about some "dead" words such as MARK/NONE etc and add categorize the opcodes themselves into colorized categories. This could help a bit more visually (e.g., I want to locate all MARK, whether I use colors or not now I won't be able to find it easily without a CTRL+F). |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Much better IMO! I would suggest not having colors for opcodes that have a colored literal (like SHORT_BINUNICODE). WDYT? |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
It would require a bit more effort to parse the literal in this case. I think the no-color option is better IMO. FTR, the MARK can be in gray as the PROTO because each MARK is followed by an indent I thnk. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I like those colors, at least they are more readable to me (and I have very poor eyesight). What about light theme though? |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I find the colors much readable now! thanks for the work
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Co-authored-by: Bénédikt Tran <[email protected]>
|
@picnixz Any further comments or ready to merge? |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| # Group opcode names into categories for colourised CLI output. | ||
| _opcode_categories = frozendict( | ||
| op_call=frozenset({ | ||
| "BUILD", "EXT1", "EXT2", "EXT4", "GLOBAL", "INST", "NEWOBJ", |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Quick question but can be done in a follow-up:
opcodes. It contains all opcodes + their protocol versions. You can use name2i but you need to remove the del name2i above in the file. Or you can build this list closer to name2i (L2200)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Alternative: add a "category" to the opcode objects. Thankfully, those objects are not tuples so we can't break things.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Yes, it covers all protocol versions. Adding a "category" is an interesting idea, but not sure this should be part of the public API. I've gone for the first suggestion.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Well, you can always make it a private attribute :) but it's not really important I think. We can revisit this later. It's only a burden when we create the list. But adding new opcodes is usually not common so... it's not really important.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Documentation build overview
5 files changed ·
|
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
Thanks for the review! |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.