add program passed as string to dis module.

[f0f7edab-0f77-471a-8c8d-7bde907388b2]

BPO	44405
Nosy	@terryjreedy, @ncoghlan, @stevendaprano, @serhiy-storchaka, @1st1, @eamanu, @CCLDArjun
PRs	python/cpython#26714
Files	dis.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = None created_at = labels = ['type-feature', 'library', '3.11'] title = 'add program passed as string to dis module.' updated_at = user = 'https://github.com/CCLDArjun' ``` bugs.python.org fields: ```python activity = actor = 'serhiy.storchaka' assignee = 'none' closed = False closed_date = None closer = None components = ['Library (Lib)'] creation = creator = 'CCLDArjun' dependencies = [] files = ['50107'] hgrepos = [] issue_num = 44405 keywords = ['patch'] message_count = 9.0 messages = ['395720', '395722', '395723', '395724', '395725', '395727', '395731', '398046', '415505'] nosy_count = 7.0 nosy_names = ['terry.reedy', 'ncoghlan', 'steven.daprano', 'serhiy.storchaka', 'yselivanov', 'eamanu', 'CCLDArjun'] pr_nums = ['26714'] priority = 'normal' resolution = None stage = 'patch review' status = 'open' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue44405' versions = ['Python 3.11'] ```

[f0f7edab-0f77-471a-8c8d-7bde907388b2]

python dis module should have a program passed in as string.

Currently, you can do this: $ echo "x = 6" | python -m dis /dev/stdin 1 0 LOAD_CONST 0 (6) 2 STORE_NAME 0 (x) 4 LOAD_CONST 1 (None) 6 RETURN_VALUE

would be convenient like this: $ ./python.exe -m dis -c "x=6" 1 0 LOAD_CONST 0 (6) 2 STORE_NAME 0 (x) 4 LOAD_CONST 1 (None) 6 RETURN_VALUE

these changes seem to be working.

[terryjreedy]

I checked https://docs.python.org/3/library/dis.html and there is no mention of dis having a command-line interface. This suggests that _test is likely present only for testing the module, not for using it. This was common a couple of decades ago before we had unittests. If _test were considered obsolete, it could be removed.

By suggesting that the command line interface by upgraded, I suspect that you are implicitly suggesting that it be considered 'official'. If so, that '_test' should become '_main' (where the underscore leaves it out of __all__), and the CLI documented as in other modules with a CLI. (I am not up on the details and policy around this issue.)

It may be appropriate to start a discussion of python-ideas.

[terryjreedy]

What is unusual, I think, for a CLI test function is that it requires a passed in argument. As a sanity-check test, 'python -m dis' could (should) disassemble itself. Perhaps there once were some true tests that were moved to unittests. (I started IDLE unittests by doing this with module test functions.) If you know git, you could check the history and checkin messages.

[f0f7edab-0f77-471a-8c8d-7bde907388b2]

Huh, that's actually weird that the "exisisting command line interface" (quotes because it was added as a test) isn't official. I've found it to be convinient as a newcomer to the cpython codebase.

What is unusual, I think, for a CLI test function is that it requires a passed in argument

git blame shows the commit hash is 095668914c3, which is for bpo: https://bugs.python.org/issue18538 "python -m dis now uses argparse". The Misc/HISTORY file references the change in section "What's New in Python 3.4.0 Alpha 3?"

Regardless of the cli being official, personally I think, it's a good feature to add. But also, maybe I should start a discussion in python-ideas about making it official?

[f0f7edab-0f77-471a-8c8d-7bde907388b2]

If _test were considered obsolete, it could be removed.

Yup, originally it was added 2 decades ago (in 2000) originally as a test: 1fdae12c932

[f0f7edab-0f77-471a-8c8d-7bde907388b2]

If _test were considered obsolete, it could be removed.

removing _test: https://github.com/CCLDArjun/cpython/commit/8b3b8ccef0ef693f8f4105fd1eb56e9386675301 does not break dis tests.

[serhiy-storchaka]

I often use the command-line interface of dis, ast, and sometimes tokenize modules. They are mature enough and not only for self-testing. If they are not documented, we need to document them.

Since they read from stdin by default (no need to specify /dev/stdin or CON explicitly) I never needed the -c option. It would not be particularly useful in any case because Python code is usually multi-line.

BTW sometimes I want to implement GUI for these modules in IDLE.

[ncoghlan]

I suspect the only reason the dis CLI isn't documented is because it's been around for so long (22 years!) that nobody previously noticed it was missing: https://github.com/python/cpython/commit/1fdae12c93246fcf4abbf882ba08df789070dfcc

Folks then either didn't know about it, or already knew how to use it.

Even the migration to use argparse was a code cleanup from a user that happened to be reading the module source code and noticed that it didn't already do so: https://bugs.python.org/issue18538

I can see value in supporting -c and -m options to dis to align with the main interpreter CLI.

[serhiy-storchaka]

Neither of tokenize, ast or symtable modules support passing the source string as argument. If add this feature in the dis module, we will need to add it in all other modules with similar CLI. I do not think it is practical. You always can pass the source string via stdin. And you do not even need to pass /dev/stdin as argument, stdin is the default.

I usually use it with rlwrap. It allows to use some editing and history.

rlwrap ./python -m dis

I propose to close this issue and open a new issue for documenting the CLI of the dis module.

[hugovk]

New issue for documenting the CLI: https://github.com/python/cpython/issues/108826

And PR: https://github.com/python/cpython/pull/108827

[serhiy-storchaka]

I suggest to close this issue.