Skip to content

Add a page to the documentation listing stdlib modules with a command-line interface (CLI) #109435

Description

@vstinner

While reviewing PR #109152, I discover that the sqlite3 module has a command line interface. Maybe I knew and then I forgot.

Is there a a documentation page listing all modules with a command-line interface (CLI)? I don't know so.

By searching for main( pattern and for __main__.py files, so far, I found:

Some modules include self-tests in their main() function. I dislike that and I would suggest to remove it and at least move it to their test suite.

  • ctypes.util: self-test
  • ctypes.textpad: demo
  • curses.has_key: self-test?
  • dbm.__init__: get the DB type... but this CLI is not easy discoverable, it's in the init module!
  • getopt: self-test
  • heapq: self-test
  • shlex: print tokens. Is it really useful?
  • imaplib: self-test, "test the IMAP4_stream class"
  • modulefinder: self-test
  • netrc: just parse ~/.netrc if available, and then display nothing... not very useful
  • random: benchmark
  • smtplib: "Test the sendmail method", try to send an email to localhost SMTP server.
  • symtable: self-test. parse itself (symtable.py)
  • turtle: it's a demo. Looks more like an easter egg or advanced example than "an useful CLI".
  • textwrap: self-test
  • tkinter: self-test
  • wsgiref.simple_server: self-test, run a server, open itself in a browser, stop the server.
  • xml.sax.expatreader: Sheakspear easter egg.
  • xml.sax.xmlreader: self-test.
  • xmlrpc.client + xmlrpc.server: simple demo.

Linked PRs

Activity

  1. added a commit that references this issue on Sep 15, 2023
  2. hugovk commented on Sep 15, 2023

    @hugovk
    Member

    There's not a page listing them, and I was also thinking it would be good to have an index.

    @simonw found 90 and wrote up some highlights on his blog recently: https://til.simonwillison.net/python/stdlib-cli-tools

    @AA-Turner Is there some existing Sphinx automation we could use for this? Mark the CLI sections and have them all listed on a single page, with some custom intro text?

    For example, we have a Superseded Modules page, but it's a manually maintained page.

  3. serhiy-storchaka commented on Sep 15, 2023

    @serhiy-storchaka
    Member

    You missed this. 😉 🥚

    Not all modules with the CLI have main() function. See for example platform.

  4. vstinner commented on Sep 15, 2023

    @vstinner
    MemberAuthor

    You missed this. 😉 🥚
    Not all modules with the CLI have main() function. See for example platform.

    I completed the list in my PR.

    I also completed the list of modules that I don't want to document in: #109435 (comment)

    IMO documenting this module CLI is worth it, but I'm open to not document it :-)

  5. vstinner commented on Sep 15, 2023

    @vstinner
    MemberAuthor

    Since https://til.simonwillison.net/python/stdlib-cli-tools was written, PEP 594 removed many modules.

  6. AA-Turner commented on Sep 15, 2023

    @AA-Turner
    Member

    Note on #109436, this was previously rejected -- we should instead aim to document command-line behaviour in appropriate places.

    A

  7. vstinner commented on Sep 15, 2023

    @vstinner
    MemberAuthor

    Ah, I was not the first one looking for such list :-)

    Decide the fate of undocumented script behavior of some modules

    I propose to remove them.

  8. hugovk commented on Sep 15, 2023

    @hugovk
    Member

    I think it's useful because https://docs.python.org/3/library/index.html is "here's a list of Python APIs you can use programmatically", and this page is "here's a list of Python APIs you can use via the command-line".

    The discussion about a re CLI shows how useful these can be for cross-platform use, for example it opens up some tools that aren't always easily accessible on Windows.

  9. serhiy-storchaka commented on Sep 15, 2023

    @serhiy-storchaka
    Member
  10. added 2 commits that reference this issue on Sep 19, 2023
  11. added a commit that references this issue on Sep 28, 2023
  12. vstinner commented on Sep 29, 2023

    @vstinner
    MemberAuthor

    #93410 proposed to display the list as a table, the idea is interesting. But I'm not interested to propose a change for that. If someone wants to enhance the list, please go ahead!

  13. merwok commented on Oct 15, 2023

    @merwok
    Member

    Could this be re-opened? This discussion was relatively short, not on python-dev and did not seem to review previous on the same topic.

    Some specific comments of interest:

    I still don’t see the use of a long list, or long table, of all the runnable modules. They don’t all have the same usefulness and audience, or the same maintained/documented status.

  14. vstinner commented on Oct 16, 2023

    @vstinner
    MemberAuthor

    Feel free to reopen the issue and/or start a new discussion if you want.

  15. reopened this on Oct 16, 2023
  16. vstinner commented on Dec 20, 2023

    @vstinner
    MemberAuthor

    @merwok: You reopened the issue but then did nothing. If you disagree with the added documentation, you can just remove it.

  17. merwok commented on Dec 20, 2023

    @merwok
    Member

    @hugovk @AA-Turner Would you object to a revert? (see comment from October 15 and the links there for justification)

  18. hugovk commented on Dec 20, 2023

    @hugovk
    Member

    I actually found it useful this week, as a quick reference to check if a certain module could be used as a CLI (secrets, it can't; I'd been thinking of uuid).

    I'd rather see it (incrementally) updated to make it more useful. IIRC there was a suggestion to group them somehow?

  19. vstinner commented on Sep 6, 2024

    @vstinner
    MemberAuthor
  20. hugovk commented on Sep 7, 2024

    @hugovk
    Member

    I still think it's useful: I told someone about it last month who said they wished they'd known about it before. There have been suggestions to show it in a table, or group them somehow. But if you want to close this issue, I think they could be new issues or PRs.

  21. pradyunsg commented on Sep 8, 2024

    @pradyunsg
    Member

    I agree that it's useful, that we should improve it incrementally, and that this issue can be closed.

    The current state where we have just a list of module references is better than nothing, and we can improve it further over time with new issues/PRs.

  22. vstinner commented on Sep 8, 2024

    @vstinner
    MemberAuthor

    I agree that it's useful, that we should improve it incrementally, and that this issue can be closed.

    Ok, I close the issue again.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    docsDocumentation in the Doc dir

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions