On 12/18/22, Jim Lewis <jimdanielle...@gmail.com> wrote: > > Sometimes it's a path issue.
For whatever reason, Python installations on Windows lack versioned executable names (except for the Microsoft Store distribution). Thus adding multiple installations to PATH doesn't help unless "python.exe" is manually linked or copied to versioned names, e.g. "python3.11.exe" -> "python.exe" and "python3.exe" -> "python.exe". In this case, the first installation in PATH is the default for running "python" and "python3". Using the "py.exe" launcher is the more general and preferred solution. It allows running any registered Python installation. It's also the installed handler for the ".py" file type, and it supports Unix-style shebangs. > Or exe naming confusion: python, python3, phthon311, etc. I don't understand what's supposedly confusing here. Here are some commands to help discover what "py" or "python" commands and installations are available. * CMD: where py*.exe * PowerShell: get-command py*.exe * Python launcher: py --list-paths > Or library compatibility issues - took an hour to find out that > pygame does not work with the current version of python. It should be a trivial task to discover that wheel packages for pygame aren't currently available for Python 3.11. It is not unreasonable to expect Python developers to familiarize themselves with pip and PyPI. If you search a bit deeper, you'll find a site with unofficial Windows builds of many packages, including pygame for Python 3.11: https://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame Otherwise, while building some packages from source can be quite involved and difficult, I'd expect anyone with a degree in computer science to be able to build pygame if necessary. They even provide a simple guide: https://www.pygame.org/wiki/CompileWindows > Then the kludgy PIP app and using a DOS box under Windows with > command prompts which is ridiculous. How is pip "kludgy" (i.e. sloppy, hasty, shoddy, or inelegant)? How is using a command-line interface "ridiculous"? Many programmers and system administrators actually prefer using command-line interfaces and text user interfaces (TUI) for many if not most development and administration tasks. It's a matter of opinion. --- Nerdy operating system discussion... > using a DOS box under Windows The term "DOS box" refers to a virtual machine running 16-bit MS-DOS in virtual 8086 (v86) mode under Windows 3.1 or Windows 9x, with the MS-DOS keyboard and display drivers hooked to redirect I/O to a desktop window. There is no "DOS box" in Windows NT systems. Windows client systems switched to NT starting with Windows XP. Thus the term "DOS box" is about two decades out of date. Also, "DOS" is not synonymous with a command-line interface shell (e.g. the 16-bit MS-DOS shell, "COMMAND.COM"). A "Disk Operating System" is one that supports disk drives and filesystems, which includes most operating systems from the late 1960s onward (e.g. DOS/360 from 1966). There were several DOS systems for personal computers in the 1980s, such as Apple ProDOS, Atari DOS, Tandy TRSDOS, Commodore DOS, and Microsoft MS-DOS. A DOS system can use a graphical shell, such as running Windows 1.0 (1985) on MS-DOS. The "python.exe" executable is a Windows application that's flagged to require a console session. If it doesn't inherit a console session, then the system allocates one automatically. However, any Windows application can allocate, attach to, and detach from a console session via AllocConsole(), AttachConsole(), and FreeConsole(). Prior to Windows 7, each console session in the current NT session is hosted on threads in the subsystem process for Windows, "csrss.exe". Starting with Windows 7, console sessions are hosted by instances of "conhost.exe". The console host also implements a builtin terminal window for command-line interface (CLI) and text user interface (TUI) applications. (A console session can be allocated without a terminal window if a console application is spawned with the creation flag CREATE_NO_WINDOW.) Prior to Windows 10, the connection between a console session and its terminal is hardwired in the console host. This makes it difficult to implement an alternate terminal, though some alternate terminals have managed to do so in creative ways (e.g. ConEmu). Starting with Windows 10, alternate terminals can use an open source implementation of the console host, named "openconsole.exe". The most important example is Microsoft's "Windows Terminal". Starting with Windows 11, an alternate terminal can also register as the default terminal for console applications. For example, if Windows Terminal is set as the default terminal, then running "python.exe" from Explorer opens a new tab in Terminal. -- https://mail.python.org/mailman/listinfo/python-list