I'm having a problem with my python installation. The packages that came with the installation work just fine but when I try to use other installed packages I run into problems. For example, I installed a package pymsgbox using pip from an admin shell. When I run a sample script from the command line as in sample, I get

ModuleNotFoundError: No module named 'pymsgbox'

but when I run it by python sample.py it works fine. Likewise if I load it into IDLE and run it from there. Suggestions?

Recommended Answers

All 8 Replies


import pymsgbox
pymsgbox.alert("some text")


Traceback (most recent call last):
  File "D:\Utils\sample.py", line 1, in <module>
    import pymsgbox
ModuleNotFoundError: No module named 'pymsgbox'

D:\Utils>python sample.py

D:\Utils> (message box is properly displayed)

To me this sounds like Python environment and path issues. We chatted about some of this and you revealed the drive letter D so my bet is that Python environment variables are what's in play. I am a little under the gun on a non-Python issue so I won't get to duplicate this till a few days.

Off topic but why I can duplicate this is that one of my test laptops is now clean and ready to do this. But I'm supposed to have my nose to the grindstone and not here. So I'll cheat a little and comment but have to delay on duplicating this here for a few days.

The first thing I thought of was environment but the only change I made was to add PYTHONPATH so that I could import from my include folder. I dummied that back out and got the same results. I still don't understand why it would make a difference whether I explicitly invoke python.exe or let Windows do it by association with the py extension. In both cases it runs the same version of python.

That sort of leads me to a gripe. Every app seems to want its own version of python. I currently have six copies of python.exe. Three for Visual Studio, two for open office, and the one I explicitly installed (the one that gets run by association). Since Visual Studio has its own copy that means it doesn't have access to pip installed packages when I use VS for debugging.

Now I'm spitballing here but I've seen the command shell FORGET environment variables when you launch by association. I'm sure there is a longer discussion on that somewhere but it is a Windows thing.

Now this is covered at https://docs.python.org/2/using/windows.html and I had to read it five times to get it. Try the assoc and ftype commands at https://docs.python.org/2/using/windows.html#executing-scripts but the way Windows revs up the python and pythonw.exe and how paths are determined is my take on why this is.

commented: Genius. +15

The second link did the trick.


D:\Utils>ftype Python.File
Python.File="C:\Windows\py.exe" "%L" %*

Note that the given file does not exist. I changed it so that it now shows:

D:\Utils>ftype Python.File
Python.File="C:\Program Files\Python36\python.exe" "%L" %*

and sample.py now recognizes the import.


Thanks for it being just a ftype away. Here the %L is a %1 unless that is because of markdown.

As a further note, there is a py.exe and a pyw.exe in the C:\Windows folder which are the executables for the 3.7 python. Nice of Microsoft to rename them so that when I went looking for conflicting python.exe versions they didn't show up. <rude word> off Microsoft.

commented: "Embrace, extend, extinguish." I can hear it now. "We changed it for security reasons." And thanks since I didn't know that. +15
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, learning, and sharing knowledge.