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.
On 28 December 2016 at 23:00, Joseph Hackman <email@example.com> wrote:
> Hey All!
> 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/
> Python-ideas mailing list
> Code of Conduct: http://python.org/psf/