Welp! You're definitely correct. Ah well.

On 28 December 2016 at 18:33, Joseph Hackman <josephhackman@gmail.com> 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).aspx

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/