I wrote a genetic algorithm program using the inspyred library with a 32bit Python2.7 version on a 64bit Win7 machine. While generating the population the program stops running when it uses memory up to 1959044K.
I have read a number of questions on this site, and I understand that it is due to a 2GB cap on 32bit programs by the OS. So I have tried to switch to a 64bit Python and install the 64bit versions of the modules I was working with, unfortunately all but one module cannot run on the 64bit platform.
I also installed pywin32 as advised in another question but that has failed to help too. This module is not a standard Python library and I have pasted it below. The error message I get is:
import AoN
ImportError: DLL load failed: %1 is not a valid Win32 application.
My understanding is that the 64bit Python does not recognize the 32bit module. I also read here: http://effbot.org/zone/python-compile.htm about compiling the source code, but I have compiled the source code in 64bit but that does not help either as it continues to give that error.
Lastly I pasted the directory path of the module in the interpreter path but that does not help too.
Is there a way to have this module run on the 64bit Python?
And please can anyone explain the process of compiling source codes and if that can help me out?
The answer is simple - it can't work. A process is either 32 or 64 bit, it's as simple as that. So if there is one module that can't run in 64 bit, one option besides re-compiling the module for 64 bit is to delegate whatever purpose it has to a second process running in 32 bit, just doing that. This might or might not be practical, depending on the actual task of the module.
Related
So, i developed a small python program with my machine.. I use some libraries like PyQt5 xlsxwriter.. Now, i get my exe with pyinstaller, but i discovered that users machine have 32bit system.. With vscode i easily change the python interpreter to rebuild with py 3.8 32 bit, but in this way, i have a error with the module import: Both PyQt5 and xlsxwriter are impossible to found.. I try to unistall e install it again, but never. I certainly wrong somthing but my basket of ideas isover..
Sorry for my English
Good day evryone!
I have one module that only runs on 32 bit python. I then have subprocesses that need to launch on 64 bit python for memory reasons. There are also about 8 modules that I need to use. I installed everything and actually had both the 32 bit and 64 bit versions running at the same time. But then had to install one more module 'datetime'. After I installed that it went back to this issue. I tried uninstalling 'datetime' and that did not fix.
OSError: [WinError 193] %1 is not a valid Win32 application
So I followed advice to do what originally seemed to allow both to run by using pip install -- pywin32==227
That said it was already satisfied so I tried
pip install -- pywin32==228 then back to pip install -- pywin32==227
Still this error
OSError: [WinError 193] %1 is not a valid Win32 application
I noticed that despite having two versions of python (32 and 64 bit) in two different folders it is storing all modules in \AppData\Roaming\Python\Python39\site-packages and I am wondering how it distinguishes between a 32 bit module install and a 64 bit.
The most frustrating thing about this issue is for one brief moment, I actually had both running so I know it is possible, but not sure how at this point. Is there a recommended way to have two (32 and 64) bit pythons running at the same time with two unique sets of modules installed? At this point, I would start over with all of the installations as needed.
The problem is that python uses the same location for site.getusersitepackages() for 32-bit and 64-bit versions of python.
It appears that your installation process for your modules is using usersitepackages because you specified the directory causing you problems was \AppData\Roaming\Python\Python39\site-packages which is usersitepackages which appears earlier than the regular site-packages in sys.path (but only if the directory exists - hence not everybody knows about usersitepackages).
This seems to be a bug with the Python release - it has annoyed me as well since I prefer to install my extensions in usersitepackages since I may not have write access to the regular site-packages directory.
You can fix it as follows:
Edit the file Lib/site.py in your Python package (of course you might not have write access - see above).
There is a function called _get_path in this file which looks a bit like this:
def _get_path(userbase):
version = sys.version_info
if os.name == 'nt':
return f'{userbase}\\Python{version[0]}{version[1]}\\site-packages'
So very good - it gets the right version of Python - but does nothing about the number of bits. Since we are recoding this function you should do this:
return f'{userbase}\\Python{version[0]}{version[1]}-32\\site-packages'
or this:
return f'{userbase}\\Python{version[0]}{version[1]}-64\\site-packages'
depending on whether you are editing the 32-bit version or the 64-bit version.
I suppose you could find out the architecture if you wanted to be pure and logical
(in order to have the same implementation of site.py for all releases).
e.g.
import platform
platform.architecture()[0]
should return 32bit or 64bit - so this is what I think the Python development team should do if they read this comment.
I have a python package that acts like a wrapper for a .dll written in C#. The binary is imported into python by the pythonnet package. Thus, the user can access the functionality of the so called cs_backend.dll conveniently from the python side. The import looks as follows:
import clr as __clr
import System as __System
__clr.AddReference(PATH_TO_CS_BACKEND + "\\cs_backend")
import cs_backend as __csb # exception thrown here
However, it seems that python can't import the .dll as I get a ModuleNotFoundError: No module named 'cs_backend'.
The odd thing is that this error only occures when running the code from Spyder. Executing exactly the same code from Visual Studio Code works perfectly fine.
Do you have any idea what the problem could be?
system specifications
os: windows 10
.net framework v4.5.1
python 3.8.5
spyder 4.2.1
Edit:
I have found a github issue on the pythonnet repository that describes a similar (although not quite the same) problem. However, since it has been open for about 3 years, it seems that there is little to no progress on that.
Edit 2:
There is a similar question here on stack overflow. The solution was to install a newer .NET Framework. This is not my problem since with any IDE other than Spyder the code works just fine. Thus, I guess that this is mainly a Spyder issue.
Currently, it seems that there is neither a solution nor an effort to resolve this problem.
It looks like the problem is caused by the IPython console integrated in Spyder.
A simple workaround is to execute the python script from the system console.
In Spyder this can be done by going to Run - Configuration per file - Execute in external system console.
With the new configuration it is at least possible to run the script.
I'm running into a cython-unicode problem which I hope you can help me with -
I'm trying to compile with cython a python module which works alot with unicode objects.
I'm working on Ubuntu 12.04 32bit, (on a VM on a Win7 64bit host if it has any importance), I'm using Py2.5.4 (can't change that) which I've installed side-by-side with the provided Py2.7.3 (and soft-linked /usr/bin/python to /usr/bin/python2.5), and Cython 19.02 (current one). I'm compiling with no special flags.
Now, as compiling goes seemingly OK, when I open a Py (same 2.5.4) and try to import the resulting. SO file, I get a PyUnicodeUCS2 type error. That is supposed to mean, as I understand, that the SO was compiled on a python configured with UCS4, and imported to python configured with UCS2. But It's the same python I compiled on and imported to.
for compilation I use $ python setup.py bild_ext --inplace where setup.py uses distutlis.extension.Extension and Cython.Distutile.build_ext .
Can someone enlighten me with what's going on and what I can do with it?
I'll be happy to provide more details if I wasn't clear enough.
Thanks a lot..
I'm using CXFreeze with PySide (QT). I get an error:
cx_Freeze: Python error in main script.
myscript.py line 33, in
File ExtensionLoader_Pyside_QtGUI.py, line 11, in
Import Error: DLL load failed: The specified module could not be found
When running a fresh install of Windows server 2008.
I'm running the frozen EXE package (with the folder). It seems to work on my own system and other systems. What might be the issue?
After reading, online, I tried to replace the Qt4Gui file, but this didn't solve the issue.
Python version is 2.7
Based on your Import Error: DLL load failed it is most likely an installation issue causing the missing DLL. To figure our exactly which DLL you are missing, use http://www.dependencywalker.com/ Run the .exe and open the .pyd file for File ExtensionLoader_Pyside_QtGUI.py and it will show you exactly which DLL's are missing and more importantly the locations where they should be. You can probably then track down the missing DLL online.
there are known issues with pyside 1.2.0 and cxFreeze. All should be fixed in development version (available on git repo). Please build the PySide from latest sources yourself or wait for PySide version 1.2.1. Build instructions are here [1].
[1] https://github.com/PySide/pyside-setup#building-pyside-on-a-windows-system
I used Py2exe instead of CXFreeze and it worked perfectly.
Also, apparently Python requires the MS Visual C++ Dependency Files:
http://www.microsoft.com/en-us/download/details.aspx?id=29
So any bundling needs that as well, if it's a fresh install. (Although I think they are now bundled with newer Windows versions.)
Other Notes:
In my experience, sometimes you should try CXFreeze, Py2EXE and PyInstaller quickly and see if one works best. As ideal as CXFreeze is re: cross platform, it just isn't going to happen perfectly.
Also, while I don't know if this was a factor, I set up a Windows 2000 Pro virtual machine and ran Py2exe on that. That was to ensure compatibility for all older Windows versions, and seemed to work well. (NOTE: Many things won't even run on Win2000 anymore so be careful that your other tools and libraries will run on it.)
Finally, be extra careful to match the bit level (32 vs 64) of all your libraries, and your Python install itself. If you have 32-bit python, ensure that your PySide, CXFreeze and any other libraries you use are 32-bit. (Or 64-bit if you're using 64-bit python.)