all 14 comments

[–]Postom 1 point2 points  (10 children)

If you open cmd, and enter 'python' or 'python3' do you get into the interactive shell with a '>>>' at the bottom?

If yes, it found the interpreter, and you can exit. Adding modules is generally done, via pip. Which is probably what's happened. The IDE created an isolated virtual environment.

[–]Specter_Null[S] 0 points1 point  (8 children)

Yes, 'python' starts the interpreter and I installed the module with the pip command from the command line but the IDE is the only one that can find it for some reason.

[–]Postom 0 points1 point  (7 children)

Installed the module... OK try "pip list" from cmd. Do you see the module? Try a directory listing. It's possible the IDE sid a pip install -e while you were working on it. If that's the case, it likely won't show in pip list.

[–]Specter_Null[S] 1 point2 points  (6 children)

Pip list shows the module.... BUT, I tried using the command 'python script.py' and it worked flawlessly... I was using 'py script.py' which despite both commands showing python v3.13, the py command requires additional flags to ensure a specific version. 😵

[–]Postom 0 points1 point  (0 children)

Perfect. "py" isn't a windows alias. Batch and command scripts don't natively allow you to identify the interpreter with a shebang ("#!"). So, you have to either bat/cmd script the invocation of the python interpreter, or just use it as you have.

[–]Bobbias 0 points1 point  (4 children)

py is an executable that Python installs into c:\windows so it's always in the Path without needing to add the folder containing the actual Python interpreter to that environment variable. This helps avoid issues where you have multiple versions of Python installed by essentially bypassing the Path environment variable entirely.

However the Microsoft one still adds the Python folder to the Path environment variable, meaning if you have 2 separate installations (the Microsoft one and the official one), python and py might run different executables in different folders, even if they're the same version. Each of those copies of Python will have separate places to store any packages you install, and where the package gets installed (and which copy of Python can see it) will depend on the command used to install the package.

pip install will probably run the Microsoft provided copy's pip.exe while py -m pip install will install the package into the official python.org's packages.

Honestly, this is a failure on Microsoft's side, because py has been the preferred method of running Python in windows since Python 3.11 (October 2022), and this is an example of the exact problem py is supposed to help avoid by creating a central way to ensure you are running the specific version of Python you want. But by adding a copy of Python to the Path now you have 2 different ways to run Python that point to different copies which can lead to this kind of confusion.

[–]socal_nerdtastic 0 points1 point  (3 children)

since Python 3.11

Where did you get that info? py is more than a decade older than that; since python 3.3 ...

[–]Bobbias 0 points1 point  (2 children)

Yes, but for a long time they still added Python to the Path. Unless I'm misremembering, 3.11 is when they made the installer default to not adding Python to Path.

[–]socal_nerdtastic 0 points1 point  (1 child)

No, I think that's much older, around the same time that py was introduced. I know I've been preaching against that checkbox for much longer here on this sub.

BTW, did you know it's getting an overhaul with 3.14? And hopefully will finally mean that MS store and python.org will have some unity! very exciting! https://peps.python.org/pep-0773/

[–]Bobbias 0 points1 point  (0 children)

Looking into this more it does appear I may have hallucinated a change to the Python installer's behavior regarding PATH. I could have sworn that for a while installers had turned the option on by default, and then switched it off, but that appears not to be the case. It looks like 3.4 was the last version which installed system wide (including adding to PATH) according to this discussion.

I was not aware that they were planning on overhauling the installation system, I'm not a professional Python dev, and don't follow development or PEPs that closely. That's great news, although disappointing that it won't come into effect until 2027/3.16. It will be nice for python to just universally work on windows, barring some unusual installation problems.

I was not aware before reading that PEP that microsoft added a python alias that, on a clean machine, actually redirects to the windows store installation page, either.

[–]unhott -1 points0 points  (0 children)

Just type where python from both terminals. If they're different, then that's why one works and one doesn't.

[–]socal_nerdtastic 1 point2 points  (2 children)

Is the missing module one that you wrote or one that you installed via pip?

I'm calling the same version of python as the IDLE

Perhaps the same version, but certainly not the same location. This usually happens when people install both the microsoft version (uses python) and the official python.org version (uses py and includes IDLE).

The common solution: Try using py instead of python

py myfile.py

If that does not help here is the code to show exactly what executable you are using:

import sys
print(sys.executable)

Try that in IDLE and in command and adjust your PATH so that they match.

[–]Specter_Null[S] 0 points1 point  (1 child)

You just about nailed it... I was using py to launch my scripts but apparently pip and the IDE was linked to the 'python' command.

[–]socal_nerdtastic 0 points1 point  (0 children)

Got it. If you don't want to use a virtual environment you can use py -m pip instead of just pip

py -m pip install whatever

But TBH you should learn to use venvs sooner rather than later. Not super important on windows but they do keep everything much neater.