Skip to content

Remove Python 2 utilities and little used utilities #3481

Description

@Rowlando13

Python2-centric utilities:

  • get_binary_stream
  • get_text_stream

Little used Utilities:

  • wrap_text
  • getchar

In the interest of making more time to focus on core click details, these utilities are planned to be deprecated in the next feature release, and removed from the public api in one after. If any of these are critical to your uses, please explain below, and we may consider other options.

Activity

  1. added this to the 8.5.0 milestone on May 19, 2026
  2. Rowlando13 commented on May 19, 2026

    @Rowlando13
    MemberAuthor

    @kdeldycke @davidism Any others to consider?

  3. kdeldycke commented on May 22, 2026

    @kdeldycke
    Collaborator

    get_binary_stream and get_text_stream are genuinely Python 2/3-era shims for the sys.stdin vs sys.stdin.buffer split, so fair game to deprecate them. Can help identified other Python 2 left-over as suspected by @davidism at #3482 (comment)

    wrap_text is used internally a lot for HelpFormatter. Also used by @janluke in https://github.com/janluke/cloup/blob/d53d04f51846e3dbfe6a1b97ad677bfc5cdda47f/cloup/formatting/_formatter.py#L239-L240. What do you want to replace it with?

    I have doubt about getchar. Is there a multi-platform equivalent in the stdlib?

  4. added
    promptInteractive input and confirmation
    help outputHelp text formatting, layout, and --help rendering
    on May 22, 2026
  5. davidism commented on May 22, 2026

    @davidism
    Member

    Not everything in utilities is compat stuff for Python 2. Pretty sure we use getchar because there's no built-in way to get a single character input (without pressing Enter) cross-platform.

  6. Rowlando13 commented on May 22, 2026

    @Rowlando13
    MemberAuthor

    Updated the issue. Plan to do a GitHub search for how much things are used. I got these from talking with people at Pycon, so just soliciting input. I am mainly concerned with reducing the public api. People are free to vendor the code, I just want to be sure it is really used if we keep it around. A fair amount of utilities have little to no test coverage, so there is maintenance work to be done if we want to keep them around.

  7. davidism commented on May 22, 2026

    @davidism
    Member

    https://sourcegraph.com/search is a good resource for that, as long as you remember to exclude forks and vendored copies of Click itself (and Typer). Here's a starting search for getchar: https://sourcegraph.com/search?q=context:global+lang:Python+-path:click+-path:typer+click.getchar&patternType=keyword&sm=0 but you also need to search for pause which uses it. There's definitely some use out there. Not sure if it's significant enough to justify, especially if things like prompt-toolkit https://python-prompt-toolkit.readthedocs.io/en/3.0.52/pages/asking_for_input.html#reading-keys-from-stdin-one-key-at-a-time-but-without-a-prompt and textual exist.

  8. davidism commented on May 23, 2026

    @davidism
    Member

    Removing colorama in #3505, I was reminded just how many ways click inspects and wraps the input and output streams. I have a feeling all of that can be removed now. The standard streams are always text. Pretty sure the encoding is always UTF-8 on all platforms now. Last year I went through and deprecated then removed all support for bytes in Werkzeug, and didn't encounter any subsequent problems. We could probably do something similar in Click: remove the behind-the-scenes wrappers, deprecate passing binary streams (users can wrap them in TextIOWrapper themselves if they have some special stream), and then remove in 9.

  9. kdeldycke commented on May 23, 2026

    @kdeldycke
    Collaborator

    Removing colorama in #3505, I was reminded just how many ways click inspects and wraps the input and output streams. I have a feeling all of that can be removed now. The standard streams are always text. Pretty sure the encoding is always UTF-8 on all platforms now. Last year I went through and deprecated then removed all support for bytes in Werkzeug, and didn't encounter any subsequent problems. We could probably do something similar in Click: remove the behind-the-scenes wrappers, deprecate passing binary streams (users can wrap them in TextIOWrapper themselves if they have some special stream), and then remove in 9.

    I like that plan. Also a bit appalled by all the stream and I/O dance I had to go through in the last couple of releases just to make things work. I mainly apply fixes locally on that front in fear of breaking something. So any streamlining attempt is welcome and I think the time is right: we have the maintainership momentum and enough accumulated tests for refactoring part of Click in 8.x before 9.0. Feel free to attempt a PR and I'll test it! :)

  10. modified the milestones: 8.5.0, 9.0.0 on Jul 8, 2026
  11. kdeldycke commented on Jul 8, 2026

    @kdeldycke
    Collaborator

    Given #3676 , I guess the milestone change to 9.0.0 is just the blast radius of the recent main <-> stable dance. So I retarget this to 8.5.0 unless an explicit decision is made.

  12. modified the milestones: 9.0.0, 8.5.0 on Jul 8, 2026
  13. Rowlando13 commented on Jul 16, 2026

    @Rowlando13
    MemberAuthor

    Decided after thinking for a bit. The real concern with utilities is continuing maintenance burden that blocks future dev, but there have been few if any issues with utilities in the last few years, so just going to leave them except the two clearly python 2 ones. On the surface they provide at least some utility. The test coverage for them is not great, so getting them to full test coverage can be a project that newer contributors can add meaningful value.

  14. locked as resolved and limited conversation to collaborators on Aug 1, 2026
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

    help outputHelp text formatting, layout, and --help renderingpromptInteractive input and confirmation

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions