Would this only apply to recent versions of Windows? (IIRC, the VT100 support is Win10 only). If so, I'd be concerned about scripts that worked on *some* Windows versions but not others. And in particular, about scripts written on Unix using raw VT codes rather than using a portable solution like colorama.
At the point where we can comfortably assume the majority of users are using a version of Windows that supports VT codes, I'd be OK with it being the default, but until then I'd prefer it were an opt-in option. Paul
On 28 December 2016 at 23:00, Joseph Hackman firstname.lastname@example.org wrote:
I propose that Windows CPython flip the bit for VT100 support (colors and whatnot) for the stdout/stderr streams at startup time.
I believe this behavior is worthwhile because ANSI escape codes are standard across most of Python's install base, and the alternative for Windows (using ctypes/win32 to alter the colors) is non-intuitive and well beyond the scope of most users.
Under Linux/Mac, the terminal always supports what it can, and it's up to the application to verify escape codes are supported. Under Windows, applications (Python) must specifically request that escape codes be enabled. The flag lasts for the duration of the application, and must be flipped on every launch. It seems many of the built-in windows commands now operate in this mode.
This change would not impede tools that use the win32 APIs for the console (such as colorama), and is supported in windows 2000 and up.
The only good alternatives I can see is adding colorized/special output as a proper python feature that actually checks using the terminal information in *nix and win32.
For more info, please see the issue: http://bugs.python.org/issue29059
Python-ideas mailing list Pythonemail@example.com https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/