You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Remove Python 2 utilities and little used utilitiesΒ #3481
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.
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)
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.
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.
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.
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! :)
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.
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.
Activity
Rowlando13 commentedon May 19, 2026
@kdeldycke @davidism Any others to consider?
kdeldycke commentedon May 22, 2026
get_binary_streamandget_text_streamare genuinely Python 2/3-era shims for thesys.stdinvssys.stdin.buffersplit, so fair game to deprecate them. Can help identified other Python 2 left-over as suspected by @davidism at #3482 (comment)wrap_textis used internally a lot forHelpFormatter. 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 thestdlib?davidism commentedon May 22, 2026
Not everything in utilities is compat stuff for Python 2. Pretty sure we use
getcharbecause there's no built-in way to get a single character input (without pressing Enter) cross-platform.Rowlando13 commentedon May 22, 2026
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.
davidism commentedon May 22, 2026
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 forpausewhich 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.davidism commentedon May 23, 2026
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
TextIOWrapperthemselves if they have some special stream), and then remove in 9.kdeldycke commentedon May 23, 2026
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! :)
kdeldycke commentedon Jul 8, 2026
Given #3676 , I guess the milestone change to 9.0.0 is just the blast radius of the recent
main<->stabledance. So I retarget this to 8.5.0 unless an explicit decision is made.Rowlando13 commentedon Jul 16, 2026
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.