The quick answer is that the MSDN doc indicates support from windows 2000 onward, with no notes for partial compatability: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686033(v=vs.85).a... I'll build a Windows 7 VM to test. I believe Python 3.6 is only supported on Vista+ and 3.7 would be Windows 7+ only? On 28 December 2016 at 18:06, Paul Moore <p.f.moore@gmail.com> wrote:

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 <josephhackman@gmail.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/issue29059

Cheers, Joseph

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, Dec 28, 2016, at 18:33, Joseph Hackman wrote:

The quick answer is that the MSDN doc indicates support from windows 2000 onward, with no notes for partial compatability: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686033(v=vs.85).a...

That's the function itself (and 2000 is just as far back as the website goes, it's actually existed, with the other modes, since NT 3.1 and Windows 95. The separate code sample page mentions that they are new features since Windows 10 Anniversary Edition.