Closed jasonzio closed 2 years ago
That hardly obviates the entire colorama project. Maybe the Windows-specific bits, but the, you know, coloring the output bits are actually used on *nix.
From the README for this project:
Colorama
Makes ANSI escape character sequences (for producing colored terminal text and cursor positioning) work under MS Windows.
There are many, many solutions for coloring text that work perfectly on Unix-like systems. What made this project necessary was the fact that those didn't work on Windows. With Win10 and Windows Terminal, those other solutions now can work.
Changing the project purpose/focus to do the things you rely on it to do is one way of resolving the issue. I guess @tartley or anyone who forks the repo gets to decide. Heck, maintaining compatibility with existing users also makes sense. But the stated primary goal of the project may be addressed through fully supported features from the OS vendor, and I thought it useful to let users know that.
I agree that since Windows is now growing (has grown?) full ANSI code support, there is no longer a need for Colorama - so long as that isn't interpreted as leaving any existing users in the lurch.
Since creating Colorama, I have wished many times that I had just "done one thing well", by only including code to convert ANSI to win32 calls, and omitting the constants to generate ANSI codes, like "Fore.RED". Had I done that, the README could simply recommend the use of other (better, and more active) projects for the purpose of generating ANSI codes, like termcolor, blessings, and rich.
However, I don't want to sabotage anyone who is already using Colorama's Fore.RED and the like, so these constants will always remain. Similarly, all users who for some reason are still running in CMD.EXE terminals (where I presume the ANSI conversion is still required), can continue using Colorama, just like always.
The troublesome case is, I suspect that the vast majority of use comes from programs that include Colorama just in case one of their users is running on a Windows platform that needs it. So people who desire to use Colorama in their projects will exist for a long time.
I plan on fixing one or two issues in the near future. But apart from that, so long as a working version of Colorama continues to be available on PyPI for those who need it, it can continue a lengthy slide into graceful retirement. (and of course, anyone who cares enough to disagree with that can always chat about becoming a maintainer, or are free to make a fork.)
I'm not sure this issue is actionable though, so am closing, unless you have a specific action in mind?
At most, an update to the project readme which lays out your future plans (as appeared in your previous reply). Closure of this issue is fine.
Good point.
Closing this. I think this issue has been taken care of by the README edits that are part of the recently merged 'just_fix_windows_console()' alternative to 'init()'.
On Windows 10, using Windows Terminal to host the python program (either hosting the entire shell or just the application) seems to address 100% of the problem space. Windows Terminal is a full-fidelity vt102 emulation with full escape sequence support. No need to use win32 APIs to drive the old Windows Console subsystem.