[issue29059] Windows: Python not using ANSI compatible console

[Terry J. Reedy]

Terry J. Reedy added the comment:

In #30075, Tithen Firion reports that "subprocess.call('', shell=True)" leaves 
the console in ANSI mode.  In Eryk Sun says that this is likely a bug in 
cmd.exe and gives improved code for putting the console in VT mode, when this 
is possible.  I closed that issue as a duplicate of this.

--
nosy: +terry.reedy
stage:  -> resolved

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29059] Windows: Python not using ANSI compatible console

[Steve Dower]

Steve Dower added the comment:

> IIRC, ANSI is somewhat incompatible with sending random binary gibberish to 
> the screen, as people accidentally do with TYPE sometimes :) But the random 
> binary gibberish may contain ANSI control sequences... That's why I'm 
> negative on making it a default.

I don't actually know how big a deal this would be. I seem to get identical 
results from "print(''.join(chr(x) for x in range(32)))" both with and without 
the VT100 flag set, though of course "print('\033[91m')" behaves differently.

But given "on by default" isn't popular, and "off by default" implies adding 
new public API that is already available either as a short ctypes snippet or a 
number of 3rd-party libraries, I think we should consider this rejected.

For future reference, the python-ideas thread starts with 
https://mail.python.org/pipermail/python-ideas/2016-December/044033.html

--
resolution:  -> rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29059] Windows: Python not using ANSI compatible console

[Glenn Linderman]

Glenn Linderman added the comment:

Re: curses... maybe that becomes a DOCS issue, to mention the available 
packages. But it would be easier, no doubt to port curses to a known existing 
escape sequence control set, than to use a bunch arcane, 
foreign-to-the-Unix-porter-that-wants-curses obscure and seldom discussed 
Windows APIs.

IIRC, ANSI is somewhat incompatible with sending random binary gibberish to the 
screen, as people accidentally do with TYPE sometimes :) But the random binary 
gibberish may contain ANSI control sequences... That's why I'm negative on 
making it a default.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29059] Windows: Python not using ANSI compatible console

[Steve Dower]

Steve Dower added the comment:

I suspect curses could be updated to fully support Windows, even without the 
VT100 mode (all the functionality has existed for years, just through a 
different interface). It really just needs someone to take on the project, and 
there are already better options out there (I forget the name, but the IPython 
team are very happy with whatever library they're using these days), so 
possibly it's more of an awareness problem that doesn't need to be solved in 
the core distro.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29059] Windows: Python not using ANSI compatible console

[Glenn Linderman]

Glenn Linderman added the comment:

Nice idea, but not by default. An easy way to switch back and forth, and to be 
sure the original mode is restored on process exit would be a win.

Most windows users want a real GUI, not curses, but compatibility with VT 
escape codes for cross-platform semi-GUI stuff could be useful... and could 
enable the stdlib curses to be included in Python for windows also? I'm not 
sure why it isn't, and "ANSI" a.k.a. VT escape codes have been available in 
Windows for a long time... but until Python 3.6.0 (thanks again Steve, and 
others), Windows console handling in Python has been extremely limited.

Also note that UniCurses and Pygcurse exist and provide similar capabilities.

--
nosy: +v+python

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29059] Windows: Python not using ANSI compatible console

[Eryk Sun]

Eryk Sun added the comment:

> As there is no good interface in core Python to the kernel32 console
> operations (and there probably shouldn't be, it would be better to be 
> consistent), I suggest just flipping the bit at startup on Windows.

I don't follow your statement about consistency. Python could adopt a built-in 
wincon module to partially support the console API, just like winreg partially 
supports the registry API. 

When _WindowsConsoleIO was being developed, I mentioned the idea of enabling VT 
mode a couple of times, but there was no interest that I could see. I don't 
think Windows devs really care much about this feature, especially since it's 
only available in Windows 10. colorama has been the popular way to get 
cross-platform support for supporting text color in terminals and the Windows 
console. There's also pyreadline, which supports VT escapes and much more. 
Enabling the console's VT mode won't simplify the implementation of colorama or 
pyreadline so long as Windows 7 and 8 are supported, which will be for several 
more years. 

One problem with enabling VT mode at startup is that it could cause 
compatibility problems with child processes. cmd faced this problem and has 
since resolved it [1] by reverting to the original console mode before 
executing a program. If Python enables VT mode at startup, there should be a 
sys variable (based on a C global) that has the original mode value. 
Applications would be able to restore the original mode to either opt out 
entirely or before executing a child process. Py_FinalizeEx would also have to 
be modified to restore the original mode before shutting down the interpreter.

[1]: http://preview.tinyurl.com/jgtcgfs

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29059] Windows: Python not using ANSI compatible console

[Steve Dower]

Steve Dower added the comment:

Sounds good. Don't focus on ease of implementation, BTW. The post and eventual 
PEP need to cover the benefits, risks and alternatives more than anything else.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29059] Windows: Python not using ANSI compatible console

[Joseph Hackman]

Joseph Hackman added the comment:

Thanks for the tip! If you hadn't said that, I probably would have written it 
into the init scripts.

I'll try to write something for python-ideas / PEP tomorrow, but have attached 
a quick patch here so I can link to this issue for an example implementation.

--
keywords: +patch
Added file: http://bugs.python.org/file46060/issue29059.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29059] Windows: Python not using ANSI compatible console

[Steve Dower]

Steve Dower added the comment:

Oh, and it should go in the WinConsoleIO class, needs to be written in C, and 
probably needs a short PEP explaining why it has to be on by default and can't 
be turned on by programs that need it. I'm sure the discussion will lead to 
other ideas as well (perhaps posting on python-ideas is a good start? Though 
there may not be a lot of discussion for a Windows-centric suggestion like 
this.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29059] Windows: Python not using ANSI compatible console

[Steve Dower]

Steve Dower added the comment:

Great suggestion. If someone is willing to contribute the work then we can 
consider it for 3.7.

If you need this functionality sooner, either ctypes or colorama should allow 
you to use it on existing releases.

--
type: behavior -> enhancement
versions: +Python 3.7 -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 
3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29059] Windows: Python not using ANSI compatible console

[Joseph Hackman]

Joseph Hackman added the comment:

The flag is application specific. I.e. a python program that writes to console  
using ansi codes, when used on windows, will just display the codes. If the 
Output is redireced to file and then the file is printed to console using a 
console tool, the colors will show instead.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29059] Windows: Python not using ANSI compatible console

[INADA Naoki]

INADA Naoki added the comment:

Is it a global state, or application specific state?
In other words, if Python enables VT100, doesn't it remain after os._exit(1)?

If it is global state of console, why Python should change it?
Shouldn't user who want to use VT100 enable it before starting Python?

--
nosy: +inada.naoki

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29059] Windows: Python not using ANSI compatible console

[Joseph Hackman]

New submission from Joseph Hackman:

On windows, Python does not request that Windows enable VT100 for console 
output for Python.

That is to say that ANSI codes such as \033[91m will function on Mac and Linux 
Pythons, but not Windows.

As there is no good interface in core Python to the kernel32 console operations 
(and there probably shouldn't be, it would be better to be consistent), I 
suggest just flipping the bit at startup on Windows.

I would be happy to submit a patch, but seek guidance on the best location for 
addition of code to 'at startup iff a tty is attached'.

The following code solves the issue:
import platform
if platform.system().lower() == 'windows':
from ctypes import windll, c_int, byref
stdout_handle = windll.kernel32.GetStdHandle(c_int(-11))
mode = c_int(0)
windll.kernel32.GetConsoleMode(c_int(stdout_handle), byref(mode))
mode = c_int(mode.value | 4)
windll.kernel32.SetConsoleMode(c_int(stdout_handle), mode)

Please see:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686033(v=vs.85).aspx 
(Search for ENABLE_VIRTUAL_TERMINAL_PROCESSING)
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683231(v=vs.85).aspx 
(As for why stdout is -11 on Windows)

--
components: Windows
messages: 283913
nosy: joseph.hackman, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows: Python not using ANSI compatible console
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com