Python 3.3 and Pygame 19.2a install problems

[edvogel56]

Hi,
I am putting together tutorials to accompany "Invent Your Own Computer Games with Python" for a volunteer gig. I installed Python 3.3 and Pygame 19.2a on an XP machine and it works fine. However the install on my Win7 (Home Edition)HP notebook is not working.

While running python code from Idle that uses Pygames I get this message:

Traceback (most recent call last):
File "C:\Users\Ed\Documents\SOMA\Minecraft and Python\inventwithpython_src\dodger.py", line 1, in <module>
import pygame, random, sys
File "C:\Python33\lib\site-packages\pygame\__init__.py", line 95, in <module>
from pygame.base import *
ImportError: DLL load failed: The specified module could not be found.


I am looking at the computers and installed directories side by side and I don't see anything "missing." That being said there is a base.pyd file butnot a base.dll. I understand .pyd files are a type of dll. Could there be something about Win7 doesn't like about that naming convention?

Please advise.

Thanks!

EdV

 

[edvogel56]

Hi,

I am putting together tutorials to accompany "Invent Your Own Computer Games with Python" for a volunteer gig. I installed Python 3.3 and Pygame 19.2a on an XP machine and it works fine. However the install on my Win7 (Home Edition)HP notebook is not working.



While running python code from Idle that uses Pygames I get this message:



Traceback (most recent call last):

File "C:\Users\Ed\Documents\SOMA\Minecraft and Python\inventwithpython_src\dodger.py", line 1, in <module>

import pygame, random, sys

File "C:\Python33\lib\site-packages\pygame\__init__.py", line 95, in <module>

from pygame.base import *

ImportError: DLL load failed: The specified module could not be found.





I am looking at the computers and installed directories side by side and I don't see anything "missing." That being said there is a base.pyd file but not a base.dll. I understand .pyd files are a type of dll. Could therebe something about Win7 doesn't like about that naming convention?



Please advise.



Thanks!



EdV

Found the answer here:
http://www.reddit.com/r/inventwithp..._importing_pygame_i_get_importerror_dll_load/

Questions but no big deal -
1. Why doesn't pygame.org have the most recent install files compatible with the most recent python? I ended up finding them here:
http://www.lfd.uci.edu/~gohlke/pythonlibs/

2. Interesting that "3.2" pygames works with "3.3" python on my XP but the Win 7 required the "3.3" pygames. Thoughts?

Thanks again.

EdV

 

[Dave Angel]

That being said there is a base.pyd file but not a base.dll. I understand .pyd files are a type of dll. Could there be something about Win7 doesn't like about that naming convention?

Please advise.

I highly doubt that. Most Windows dlls have some other extension,
and I can't believe Win7 breaking such a long tradition.


I would instead guess that you have a path problem, either with
sys.path or with Windows PATH variable.

 

[Terry Reedy]

Found the answer here:
http://www.reddit.com/r/inventwithp..._importing_pygame_i_get_importerror_dll_load/

Questions but no big deal - 1. Why doesn't pygame.org have the most
recent install files compatible with the most recent python I ended
up finding them here: http://www.lfd.uci.edu/~gohlke/pythonlibs/

The base problem is that Microsoft changes the Visual C runtime with
each version of the VC compiler. Python 3.3 was compiled with a newer
version. It is a nuisance for packages to keep recompiling with a new VC
version. Py 3.4 is using the same version as 3.4, so PyGames *might*
work with 3.4, or there might be other compatibilities.

2. Interesting that "3.2" pygames works with "3.3" python on my XP
but the Win 7 required the "3.3" pygames. Thoughts?

It is possible that the VC++2010 runtime does not work with XP, but
requires Vista+ and that the Microsoft installer installs the older
VC++2008 runtime on XP even when installing 3.3. If you install for a
single user, the vcxxxxx.dll is in the python directory or subdirectory.
For all-user installs, it is in one of the windows/systemxx directories.
But this is just a guess.

 

[edvogel56]

The base problem is that Microsoft changes the Visual C runtime with

each version of the VC compiler. Python 3.3 was compiled with a newer

version. It is a nuisance for packages to keep recompiling with a new VC

version. Py 3.4 is using the same version as 3.4, so PyGames *might*

work with 3.4, or there might be other compatibilities.







It is possible that the VC++2010 runtime does not work with XP, but

requires Vista+ and that the Microsoft installer installs the older

VC++2008 runtime on XP even when installing 3.3. If you install for a

single user, the vcxxxxx.dll is in the python directory or subdirectory.

For all-user installs, it is in one of the windows/systemxx directories.

But this is just a guess.

Thanks much. Glad to be getting these ideas in mind before I start having kids do installations and not have something intelligent to talk about whenthings don't work. I am more interested in having them explore programming but an important part of our work is how to deal with frustration and unexpected problems.

 

[MRAB]

The base problem is that Microsoft changes the Visual C runtime with
each version of the VC compiler. Python 3.3 was compiled with a newer
version. It is a nuisance for packages to keep recompiling with a new VC
version. Py 3.4 is using the same version as 3.4, so PyGames *might*
work with 3.4, or there might be other compatibilities.


It is possible that the VC++2010 runtime does not work with XP, but
requires Vista+ and that the Microsoft installer installs the older
VC++2008 runtime on XP even when installing 3.3. If you install for a
single user, the vcxxxxx.dll is in the python directory or subdirectory.
For all-user installs, it is in one of the windows/systemxx directories.
But this is just a guess.

I've used Visual C++ Express 2010 on XP Pro without any problem.

 

[Terry Reedy]

On 2014-02-03 06:43, Terry Reedy wrote:

The names are msvcxxxx.dll and specifically msvcrtxxx.dll

I've used Visual C++ Express 2010 on XP Pro without any problem.

The question I was trying to answer is why code compiled with VC2010
would act differently (work with 3.2 or not) on xp and win7. When
running of win7, the code can use system calls that did not exist in xp.
When running on xp, the code must do something different (probably
slower, if not stop). Exactly where the different paths reside is not so
important.