Re: Fwd: Installation hell
Personally I use winpython: https://winpython.github.io/ That have all the scientific packages already available. It can run without being installed and uses spyder as an IDE (for small projects it's ok). And, I can import pygame (even though I have not tested if everything works) in python 3.11. As I'm using it for science projects I find it perfect. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/20/2022 8:11 AM, Eryk Sun wrote: [snipped] I know we're not here to bash Windows, but... drive letters really need to just die already. I don't foresee drive-letter names getting phased out of Windows. And Windows itself is unlikely to get phased out as long as Microsoft continues to profit from it, as it has for the past 37 years. Microsoft won't get rid of them for backwards compatibility reasons, aside from the sheer difficulty of changing all that code. The company has always been very industrious about keeping backwards compatibility for Windows. I have compiled Delphi Windows GUI code from 2003 and even earlier that still runs, as one example. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/19/22, Chris Angelico wrote: > On Tue, 20 Dec 2022 at 09:12, Thomas Passin wrote: > >> @echo off >> setlocal >> : Find effective drive for this file. >> set ed=%~d0 >> path %ed%\python37\Scripts;%ed%\python37;%PATH% For reference, in case not everyone on the list knows what "%~d0" means, the CMD shell supports extracting the drive (d), path (p), name (n), and extension (x) components of a path name that's stored in a parameter such as "%0". The full path (f) is resolved beforehand. For example: C:\Temp>set var=spam\eggs.py C:\Temp>for %c in (%var%) do @echo drive: "%~dc" drive: "C:" C:\Temp>for %c in (%var%) do @echo path: "%~pc" path: "\Temp\spam\" C:\Temp>for %c in (%var%) do @echo name: "%~nc" name: "eggs" C:\Temp>for %c in (%var%) do @echo extension: "%~xc" extension: ".py" C:\Temp>for %c in (%var%) do @echo full path: "%~dpnxc" full path: "C:\Temp\spam\eggs.py" C:\Temp>for %c in (%var%) do @echo full path: "%~fc" full path: "C:\Temp\spam\eggs.py" > So much easier to do on a Unix-like system, where you don't need to > concern yourself with "effective drive" and can simply use relative > paths. A relative path in the PATH environment variable would depend on the current working directory. Surely the added paths need to be absolute. However, Thomas didn't have to reference the drive explicitly. The expression "%~dp0" is the fully-qualified directory of the executing batch script, and an absolute path can reference its ancestor directories using ".." components. > I know we're not here to bash Windows, but... drive letters > really need to just die already. I don't foresee drive-letter names getting phased out of Windows. And Windows itself is unlikely to get phased out as long as Microsoft continues to profit from it, as it has for the past 37 years. The drive concept is deeply ingrained in the design of NT, the Windows API, shells, and applications. While assigning drive names "A:", "B:", and "D:" to "Z:" can be avoided, the system volume, i.e. drive "C:", still has to be accessed in the normal way, or using another one of its persistent names, such as r"\\?\BootPartition". The latter still uses the filesystem mount point on the root path of the device (e.g. "?\\BootPartition\\"), which you probably take issue with. That's a deeply ingrained aspect of Windows. Even mount points set on filesystem directories are actually bind mount points that ultimately resolve to the root path on the volume device (e.g. "\\Device\\HarddiskVolume4\\"). This differs from how regular mount points work on Unix, for which a path like "/dev/sda1/etc" is gibberish. Below I've outlined the underlying details of how logical drives (e.g. "C:"), UNC shares (e.g. r"\\server\share"), other device names, and filesystem mount points are implemented on NT. --- NT Device Names In contrast to Unix, NT is organized around an object namespace, not a root filesystem. Instances of many object types can be named. Some named object types also support a parse routine for paths in the namespace of an object (e.g. the configuration manager's registry "Key" type and the I/O manager's "Device" type). The object manager uses two object types to define the object namespace: Directory and Symbolic Link. Directory objects form the hierarchical tree. At the base of the tree is the anonymous root directory object (i.e. "\\"). A directory is implemented as a hashmap of named objects. A directory can be set as the shadow of another directory, creating a union directory for name lookups. Unless otherwise stated, the following discussion uses "directory" and "symlink" to refer to a directory object and a symbolic-link object, respectively -- not to a filesystem directory or filesystem symlink. A canonical NT device name (e.g. "C:", "PIPE", "UNC") is implemented in the object namespace as a symlink that targets the path of a real device object. The real device is typically in the r"\Device" directory. A canonical device name might be a persistent name for an enumerated device (e.g. "C:" -> r"\Device\HarddiskVolume2"). In some cases the real device name is persistent, but it's different from the canonical name (e.g. "PIPE" -> r"\Device\NamedPipe", or "UNC" -> r"\Device\Mup"). The symlink that implements a canonical device name is created either in the r"\Global??" directory or in a directory that's used for local device names in a given logon session (e.g. r"\Sessions\0\DosDevices\"). The global device directory generally contains system devices. Mapped drives and substitute drives typically use a local device directory, so users don't have to worry about conflicting drive assignments in these cases. The global device directory is the shadow of each local device directory, forming a union for name lookups. If the same device name is defined in both the local and global directories, the local device name takes precedence. However, each local device directory also contains
Re: Fwd: Installation hell
On Tue, 20 Dec 2022 at 10:01, Thomas Passin wrote: > > On 12/19/2022 5:16 PM, Chris Angelico wrote: > > On Tue, 20 Dec 2022 at 09:12, Thomas Passin wrote: > >> FWIW, I once set up a Python installation so that it could run from a > >> USB stick (Windows only). My launcher was a batch file that contained > >> the following: > >> > >> @echo off > >> setlocal > >> : Find effective drive for this file. > >> set ed=%~d0 > >> path %ed%\python37\Scripts;%ed%\python37;%PATH% > >> set PYTHONUSERBASE=%ed%\user\python > >> set HOME=%ed%\user\python > >> call python %* > >> endlocal > >> > > > > So much easier to do on a Unix-like system, where you don't need to > > concern yourself with "effective drive" and can simply use relative > > paths. I know we're not here to bash Windows, but... drive letters > > really need to just die already. > > Considering that this was for a removable drive, the launcher needed to > know its own location, which might change from one instance to another. > If you look at the code above, you won't find an obvious drive letter. > You would need to do the equivalent on Linux. The Windows drive letter > is just not relevant here. The only thing that's relevant is the *path*. Everything can be made relative to a single directory. On Unix-like systems, any relative path can be made absolute with reference to a single directory - most commonly the current working directory, of which there is precisely one. On Windows, there is the current working directory, plus twenty-six ADDITIONAL reference directories, plus a current drive (I'm not certain whether "current working directory" is the same as "current drive + current directory on that drive", so maybe there's one fewer than this). If you create a Python virtual environment without symlinks (eg "python3 -m venv env --copies"), you can run Python scripts using that environment simply by invoking the corresponding Python interpreter, regardless of the actual path. Trivially easy, because it's simply relative paths. On Tue, 20 Dec 2022 at 10:03, Grant Edwards wrote: > > On 2022-12-19, Chris Angelico wrote: > > > So much easier to do on a Unix-like system, where you don't need to > > concern yourself with "effective drive" and can simply use relative > > paths. I know we're not here to bash Windows, but... drive letters > > really need to just die already. > > They needed to "die already" 40 years ago. I was a Unix user before > MS-DOS came out, and I was rather stunned by the whole drive letter > thing. It seemed like such a giant step backwards. I figured that once > hard drives became common, drive letters would die. Nope, they're > still failing strong! They feel like part of an old style of concrete identifiers, like working with direct memory addresses (as opposed to virtual memory pages), until you realise that even MS-DOS had a special hack that let a single physical drive behave as both A: and B: with system-provided prompts "please insert disk for drive A/B" when needed. And with the SUBST and JOIN commands, you could - again, even in MS-DOS - mount directories as drives or drives as directories. (I don't remember what happened if you tried to use both at once to have a directory appear in a different location - the equivalent of a bind mount. Might have worked.) People could have destroyed drive letters by just always turning them into directories, and then comfortably moving to a Unix-like mount system, but since that didn't happen, generations of Windows users have grown up with the expectation that drive letters are a thing. And that leads to myriad problems. Until Steve Dower got involved with the Python installers, there were periodic issues resulting from certain combinations of (a) installing Python somewhere other than the C: drive, (b) using pip from somewhere other than the C: drive to install packages, and (c) attempting to use those packages from somewhere other than C:. I don't remember exactly what the solutions were (I want to say that "use explicit paths" was part of it, but this was a while ago and my memory of other people's problems isn't the greatest), but it was often a mess. Chrsia -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 2022-12-19, Chris Angelico wrote: > So much easier to do on a Unix-like system, where you don't need to > concern yourself with "effective drive" and can simply use relative > paths. I know we're not here to bash Windows, but... drive letters > really need to just die already. They needed to "die already" 40 years ago. I was a Unix user before MS-DOS came out, and I was rather stunned by the whole drive letter thing. It seemed like such a giant step backwards. I figured that once hard drives became common, drive letters would die. Nope, they're still failing strong! -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/19/2022 5:16 PM, Chris Angelico wrote: On Tue, 20 Dec 2022 at 09:12, Thomas Passin wrote: FWIW, I once set up a Python installation so that it could run from a USB stick (Windows only). My launcher was a batch file that contained the following: @echo off setlocal : Find effective drive for this file. set ed=%~d0 path %ed%\python37\Scripts;%ed%\python37;%PATH% set PYTHONUSERBASE=%ed%\user\python set HOME=%ed%\user\python call python %* endlocal So much easier to do on a Unix-like system, where you don't need to concern yourself with "effective drive" and can simply use relative paths. I know we're not here to bash Windows, but... drive letters really need to just die already. Considering that this was for a removable drive, the launcher needed to know its own location, which might change from one instance to another. If you look at the code above, you won't find an obvious drive letter. You would need to do the equivalent on Linux. The Windows drive letter is just not relevant here. (and I thought we weren't going keep on bashing non-preferred operating systems). -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On Tue, 20 Dec 2022 at 09:12, Thomas Passin wrote: > FWIW, I once set up a Python installation so that it could run from a > USB stick (Windows only). My launcher was a batch file that contained > the following: > > @echo off > setlocal > : Find effective drive for this file. > set ed=%~d0 > path %ed%\python37\Scripts;%ed%\python37;%PATH% > set PYTHONUSERBASE=%ed%\user\python > set HOME=%ed%\user\python > call python %* > endlocal > So much easier to do on a Unix-like system, where you don't need to concern yourself with "effective drive" and can simply use relative paths. I know we're not here to bash Windows, but... drive letters really need to just die already. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/19/2022 4:54 PM, Thomas Passin wrote: On 12/19/2022 3:34 PM, j wrote: I was unclear. I use the full path to the folder with the unzipped python-embedded. I shouldn't have said 'set'. I have complained on here before about broken installs but got indifference. An installer should install stuff correctly (leaving a working environment). If it won't then give clear instructions on how to install manually then let us do it. A broken installer is like a road that just runs out. Yes, I've had a few of those, just not with Python so far. One problem with a list like this is that if other people don't have the problem or can't make it happen, then they don't have any suggestions based on personal experience. So they can't be helpful. In this issue, I'm in that category. In that situation, we (the list-people, I mean) need good information to have a chance of being helpful. But I've observed that many requestors for help like this - especially installation issues - don't provide any useful particulars. That makes it seem like they don't understand what they are doing, and folks would like them to do their homework and think about what it would take for other people to have a chance of helping. Would you try to cook a meal, and then say "I followed the recipe and it didn't work, please help"? It's impossible. But I've seen this kind of question over and over on this list. I did once have a Python installation problem. The installed Python executable worked, but later I ran into some permissions problem. I had installed for "everyone", so it installed into Program Files, and apparently somewhere along the way I had done something odd to the permissions for that directory. I was never sure what. I uninstalled, and since then I have always installed new versions for just one user (me). Never a problem since. I'm sorry to say that I have never tried an embedded install, and I don't know what's different about one. Maybe I'll try one now, just to know. FWIW, I once set up a Python installation so that it could run from a USB stick (Windows only). My launcher was a batch file that contained the following: @echo off setlocal : Find effective drive for this file. set ed=%~d0 path %ed%\python37\Scripts;%ed%\python37;%PATH% set PYTHONUSERBASE=%ed%\user\python set HOME=%ed%\user\python call python %* endlocal I suppose anyone trying to use an embedded version of Python would have to set up some environmental variables in a similar way. Note that I used the "user" directory on the USB stick as a home directory for the installation. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/19/2022 3:34 PM, j wrote: I was unclear. I use the full path to the folder with the unzipped python-embedded. I shouldn't have said 'set'. I have complained on here before about broken installs but got indifference. An installer should install stuff correctly (leaving a working environment). If it won't then give clear instructions on how to install manually then let us do it. A broken installer is like a road that just runs out. Yes, I've had a few of those, just not with Python so far. One problem with a list like this is that if other people don't have the problem or can't make it happen, then they don't have any suggestions based on personal experience. So they can't be helpful. In this issue, I'm in that category. In that situation, we (the list-people, I mean) need good information to have a chance of being helpful. But I've observed that many requestors for help like this - especially installation issues - don't provide any useful particulars. That makes it seem like they don't understand what they are doing, and folks would like them to do their homework and think about what it would take for other people to have a chance of helping. Would you try to cook a meal, and then say "I followed the recipe and it didn't work, please help"? It's impossible. But I've seen this kind of question over and over on this list. I did once have a Python installation problem. The installed Python executable worked, but later I ran into some permissions problem. I had installed for "everyone", so it installed into Program Files, and apparently somewhere along the way I had done something odd to the permissions for that directory. I was never sure what. I uninstalled, and since then I have always installed new versions for just one user (me). Never a problem since. I'm sorry to say that I have never tried an embedded install, and I don't know what's different about one. Maybe I'll try one now, just to know. Dismissals about 'lazy people' (for example) aren't helpful if you are trying to get some actual work done. Yes, that's true. Lack of clear information isn't helpful, either. Well this is getting too long, and not directly helping with any of your problems. I hope it may be informative for others who want to ask for help. To be able to help someone, I have to understand just what they were trying to do, what they did, what happened that caused them to think their efforts failed, and what error messages the system emitted. That may not be enough either, but it's a required starting point. Without this kind of information, people who want to help feel frustrated. jan On 19/12/2022 17:55, Thomas Passin wrote: On 12/19/2022 12:28 PM, j via Python-list wrote: I agree. Wasted too much time on last few installs. It got to the point I downloaded python-embedded, unzipped it and set the path manually for my work (needed it as part of a compiler). I don't set those paths. If you have several different versions installed, who knows which one the path will find first? Probably not the one you want. Without paths to the script files, I need to set them temporarily, navigate to to the right directory first, or create a dedicated batch file, but at least I get the right ones that way. I don't find it to be a problem. It ain't good enough. And I like python. jan On 18/12/2022 11:50, Jim Lewis wrote: I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/19/22 13:34, j via Python-list wrote: I was unclear. I use the full path to the folder with the unzipped python-embedded. I shouldn't have said 'set'. I have complained on here before about broken installs but got indifference. An installer should install stuff correctly (leaving a working environment). If it won't then give clear instructions on how to install manually then let us do it. A broken installer is like a road that just runs out. Dismissals about 'lazy people' (for example) aren't helpful if you are trying to get some actual work done. jan I don't think there was an intent to be dismissive, just to point out that this list, and the tutor list, and other places *do* get questions from people who haven't tried very much, and don't tell their readers what they've tried, jrather ust go "it's broken, please fix it for me". You can call that lazy or not (I personally would not throw out that term); it does happen. The Python installer has a few specific people working on it, most of us here aren't in a position to make changes to it - complaining here can get sympathy, or not, but probably not action. It does seem to work out for a lot of people, so it's always a bit of a surprise when it doesn't. I'd say you ought to file an issue on it if it's broken for you - not to say you haven't tried that already. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
I was unclear. I use the full path to the folder with the unzipped python-embedded. I shouldn't have said 'set'. I have complained on here before about broken installs but got indifference. An installer should install stuff correctly (leaving a working environment). If it won't then give clear instructions on how to install manually then let us do it. A broken installer is like a road that just runs out. Dismissals about 'lazy people' (for example) aren't helpful if you are trying to get some actual work done. jan On 19/12/2022 17:55, Thomas Passin wrote: On 12/19/2022 12:28 PM, j via Python-list wrote: I agree. Wasted too much time on last few installs. It got to the point I downloaded python-embedded, unzipped it and set the path manually for my work (needed it as part of a compiler). I don't set those paths. If you have several different versions installed, who knows which one the path will find first? Probably not the one you want. Without paths to the script files, I need to set them temporarily, navigate to to the right directory first, or create a dedicated batch file, but at least I get the right ones that way. I don't find it to be a problem. It ain't good enough. And I like python. jan On 18/12/2022 11:50, Jim Lewis wrote: I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user -- https://mail.python.org/mailman/listinfo/python-list
RE: Fwd: Installation hell
This type of response is not called for. I thought this list was designed to help people. That's not what this person was doing. Everyone has different experience levels and backgrounds. Help them learn. Don't berate them. Here's what was said: Issues installing python and sending an email? Ask for a refund on your compsci degree. -Original Message- From: Python-list On Behalf Of DFS Sent: Monday, December 19, 2022 12:58 PM To: python-list@python.org Subject: Re: Fwd: Installation hell On 12/18/2022 6:50 AM, Jim Lewis wrote: > I'm an occasional user of Python and have a degree in computer science. > Almost every freaking time I use Python, I go through PSH (Python > Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. > Or exe naming confusion: python, python3, phthon311, etc. Or library > compatibility issues - took an hour to find out that pygame does not > work with the current version of python. Then the kludgy PIP app and > using a DOS box under Windows with command prompts which is > ridiculous. God only knows how many novice users of the language (or > even intermediate users) were lost in the setup process. Why not clean > the infrastructure up and make a modern environment or IDE or > something better than it is now. Or at least good error messages that > explain exactly what to do. Even getting this email to the list took numerous steps. > > -- A frustrated user Issues installing python and sending an email? Ask for a refund on your compsci degree. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/18/2022 6:50 AM, Jim Lewis wrote: I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user Issues installing python and sending an email? Ask for a refund on your compsci degree. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/19/2022 12:28 PM, j via Python-list wrote: I agree. Wasted too much time on last few installs. It got to the point I downloaded python-embedded, unzipped it and set the path manually for my work (needed it as part of a compiler). I don't set those paths. If you have several different versions installed, who knows which one the path will find first? Probably not the one you want. Without paths to the script files, I need to set them temporarily, navigate to to the right directory first, or create a dedicated batch file, but at least I get the right ones that way. I don't find it to be a problem. It ain't good enough. And I like python. jan On 18/12/2022 11:50, Jim Lewis wrote: I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
I agree. Wasted too much time on last few installs. It got to the point I downloaded python-embedded, unzipped it and set the path manually for my work (needed it as part of a compiler). It ain't good enough. And I like python. jan On 18/12/2022 11:50, Jim Lewis wrote: I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On Mon, 19 Dec 2022 at 06:10, Mats Wichmann wrote: > Why? Python is a command-line tool to process a language, Similar to > many other languages - Go, for example. Or a C/C++ compiler. *Or* you > can choose to use someone's wrapping of that process inside an > Integrated Development Environment. There are tons that support Python > and let you run your code from within the editor environment without > having to go open a cmd.exe or powershell box. Most of those are > external, but the comes-with-Python IDLE works well, too. I wouldn't bother responding to these sorts of people. They have already decided that it's impossible to find any sort of decent IDE for Python (despite pretty much every editor out there having Python support), are deathly afraid of command lines, and yet feel the need to join a mailing list to tell us all that. You won't convince them of anything. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/18/22 04:50, Jim Lewis wrote: I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. It's usually best to wait a bit after a new Python releases, until the myriad packages developed externally which depend on the binary ABI catch up. *Some* carefully follow the beta release cycle and are ready on or close to day 1, some feel like they have enough other work to do and are not. Can understand both viewpoints. You can check - search for something that's important to you on pypi.org and see if binary wheels are available. e.g. https://pypi.org/project/pygame/#files New Python releases are only once a year, so this shouldn't be too huge a burden, Python 3.10 works just fine in the meantime. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. Why? Python is a command-line tool to process a language, Similar to many other languages - Go, for example. Or a C/C++ compiler. *Or* you can choose to use someone's wrapping of that process inside an Integrated Development Environment. There are tons that support Python and let you run your code from within the editor environment without having to go open a cmd.exe or powershell box. Most of those are external, but the comes-with-Python IDLE works well, too. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user -- https://mail.python.org/mailman/listinfo/python-list
Fwd: Installation hell
I'm an occasional user of Python and have a degree in computer science. Almost every freaking time I use Python, I go through PSH (Python Setup Hell). Sometimes a wrong version is installed. Sometimes it's a path issue. Or exe naming confusion: python, python3, phthon311, etc. Or library compatibility issues - took an hour to find out that pygame does not work with the current version of python. Then the kludgy PIP app and using a DOS box under Windows with command prompts which is ridiculous. God only knows how many novice users of the language (or even intermediate users) were lost in the setup process. Why not clean the infrastructure up and make a modern environment or IDE or something better than it is now. Or at least good error messages that explain exactly what to do. Even getting this email to the list took numerous steps. -- A frustrated user -- https://mail.python.org/mailman/listinfo/python-list
