Problems about my Python installation that could make me crazy

I’ve installed Python 3.11 at my brand new win 11 machine.
As expected it runs just as fine as Python 2.?? did on my win 7 machine.
I can execute all the old programs, like:
c:> MyPythonProgram /color=blue
It is without the .py extension (thats in pathext) and I dont use python before program-name.
Then I would use some colorama features like: print(Fore.BLUE,inline), so I installed the colorama module using “PIP install colorama”. No problem, all fine.
Python still denied the existence of Colorama and (also seaborn).
I checked with “PIP show Colorama” and got a nice list of its presence.
Also I could “dir colorama* /s” to see it was there.
I found that I could trick it to work by doing so:
c:> type some.txt | python pipe.py
This does work. But it is ugly compared to:
c:> type some.txt | pipe

I decided to uninstall Python. Something could have gone wrong in the first installation, though I got all the right confirmations.
I did uninstall from “download Python” and also from the “control/programs & features” in windows.
Then I installed python from python.org (this time not letting me be tricked by the Windows store).
The problem persists.

I am a little sceptical about the place where it is installed:
Volume in drive C is OS
Directory of C:\Users\torbe\AppData\Local\Microsoft\WindowsApps
28/07/2023 20:54 0 python.exe

I am out of ideas how to make it work right.

I would recommend taking a look at Thonny. If you install that and still have problems installing packages or running a script, we can both be on exactly the same setup and it will be easier to diagnose.

Usually this means you have two Python’s installed, and the pip command you use doesn’t belong to the python command registered with Windows for the .py extension. This can happen for many reasons.

Some commands you can try to see where everything is:

  • where pip
  • where python
  • py -0
  • echo import sys;print(sys.executable) > print_python_location.py && print_python_location

Does the last one match the first one?

You can also check that in the Windows settings for “Apps → Default apps”, the .py file type is “associated with a Python app that has a rocket on its icon” as described here.

Tnx for the reply.
YES! It was some sort of double installation.
I uninstalled (again) and inspected with dir \python.exe /S where the culprit might be.
I deleted all folders that tasted like Python. And also some “linkfiles” located in a temp folder in my userarea. Especially Python.exe of size 0.
Then install and rush to get the colorama module.
It now compiles.
But sadly I dont get colours I get Ansi escape sequences.

BLUE
ESC[34m Your current rank is: 103

That worked on the old machine.
I am using ANSIcon by Jason Hood. And it works fine for my prompt and some utilities I have.
The only difference is ANSIcon is now x64.

Nice echo command you showed. Python from the prompt! :slightly_smiling_face:

Thonny is a fine program.
I’ve solved the cross installed problem.
One issue:
Thonny interferes when you run a python program from the prompt. eg.: c:> Myprogram.py
I disabled Thonnys capture of the .py extension.
I will certainly use Thonny in future (Notepad is not up to the task).

That’s because, when you use colorama, that’s what your program actually outputs. Understanding those as instructions to colour the text, is the job of the terminal window, which is a separate program. If you are having trouble making a terminal do what it used to now that you updated to Windows 11, that is a Windows 11 support question.

Dear Karl.
You are on the wrong tracks.

Actually I solved it this way:

  colorama.init()

That sentence wasnt needed in the past. It is now, so I added it. And voila everything works to my satisfaction.
I think the init() activates the ANSI hidden inside Windows. ANSI disappeared (for the users) with XP.
But the sharp eyed CMD user will notice the bright filenames in
findstr e *.py

Python can do the same - and much much more.
With the missing init() it is proved Python do this by ANSI.

So the support question for Windows should be:
WHY is ANSI such a secret in all versions since XP?

colorama.init() wraps sys.stdout and sys.stderr. If you only need to enable support for virtual terminal sequences in the Windows console screen buffer, instead call colorama.just_fix_windows_console().

VT mode is enabled by the class colorama.AnsiToWin32, and ultimately by colorama.winterm.enable_vt_processing(). This enables the flag ENABLE_VIRTUAL_TERMINAL_PROCESSING in the console screen buffer. After that, VT sequences will be processed when written to the console via WinAPI WriteFile() or WriteConsoleW().

VT mode should be enabled by default if you’re using Windows Terminal. To enable VT mode by default for the builtin console host, in the registry key “HKCU\Console”, set a value named “VirtualTerminalLevel” to the DWORD value 1.

Note that this has nothing to do with the CMD shell. If you run “python.exe” from the CMD shell or PowerShell, the shell is just waiting in the background for Python to exit. If you run “python.exe” from a GUI application such as Explorer, then it allocates its own console session. Each console session is hosted either by an instance of “conhost.exe” for the builtin console, or by “openconsole.exe” under Windows Terminal. The console host also creates and manages a terminal window if it’s not running windowless or in pseudoconsole mode.

For Windows NT systems prior to Windows 7, sessions for the builtin console were hosted on threads in the Windows server process “csrss.exe”, which is a SYSTEM process. This design wasn’t fully compatible with changes made in Windows Vista to improve the security of the window manager, so in Windows 7 the host for console sessions was moved into instances of “conhost.exe”, which runs in the security context of the allocating process. Anyway, since the console was hosted by the Windows server prior to Windows 7, it was never really clear to a lot of users exactly which component implemented it, and most users mistakenly believed that “cmd.exe” implemented the console session and terminal window. But “cmd.exe” is a regular console application that uses a console session, just like “python.exe”.

When you talk about ANSI disappearing since Windows XP, that implies it was the first version of Windows NT that you ever used. Windows NT was released in 1993. It’s based on the NT kernel instead of MS-DOS. Back then, Windows NT was mostly used on servers and high-end workstations. Otherwise, most systems used Windows 3.x or Windows 9x, which extends MS-DOS. The last Windows 9x release was Windows ME in 2000. Under Windows 3.x and Windows 9x, the console was an MS-DOS VM, with its screen buffer and keyboard input redirected to a window (if not running in full-screen mode). You could load the MS-DOS “ansi.sys” driver to get support for ANSI escape sequences. In Windows NT systems, the host for console sessions didn’t support virtual terminal sequences until Windows 10 in 2015.

1 Like