I installed SublimeREPL in Sublime Text 3, and it's working great. However, whenever I try to import a module that uses _socket such as urllib2 and urllib, it gives me an ImportError. I ran os.path to verify that the path was correct. It also works perfectly fine from the python command line, just not in SublimeREPL.
>>> import urllib2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "E:\Python27\lib\urllib2.py", line 94, in <module>
import httplib
File "E:\Python27\lib\httplib.py", line 71, in <module>
import socket
File "E:\Python27\lib\socket.py", line 47, in <module>
import _socket
ImportError: DLL load failed: %1 is not a valid Win32 application.
You're almost certainly mixing Python installations. That is, you've got SublimeREPL using a 64-bit Python, but you've also got a 32-bit Python on the same machine, and your PYTHONPATH is configured to point at the 32-bit Python's library instead of/ahead of its own.
Or, worse, you installed both Pythons to the same directory, and you have a single installation which is part 64-bit and part 32-bit. (If that's the case, you'll get the same error using Python from the command line.)
Mixing native and Cygwin Pythons, CPython and IronPython, or occasionally even two builds compiled with different flags, or two different X.Y versions, can also cause this, but 32-bit and 64-bit are the most common reason.
The reason urllib2 itself loads is that Python 2.7 source is Python 2.7 source code; it doesn't matter what build it comes from. But C extensions compiled into DLLs are compiled against a specific Python interpreter, and only work on that interpreter. If the Windows DLL loader hadn't refused to let Python get any further, you'd just get a different error a moment later.
While we're at it, Python improved the error handling for this case somewhere around 3.3, making it a little easier to tell what's going on, but of course if you stick with 2.7 you don't get new features.
From inside Python, the quickest way to tell if you're in a 32-bit or 64-bit interpreter is sys.getmaxsize. If it's about 2 or 4 billion, you're 32-bit; if it's about 9 or 18 too-many-digits-to-count-illion, you're 64-bit.
To find out whether a DLL is 32-bit or 64-bit is apparently a lot harder on Windows than on any other platform in the universe. See this question or this one for details.
I ran into the same problem. I suspected it had to do with using SublimeText 3 64bit and using a 32bit Python 3 for SublimeREPL.
I uninstalled Python 3 32bit, and installed 64bit Python 3 but this presented a new error about a version mismatch. I had installed Python 3.4 and my current version of SublimeText bundles Python 3.3.
So, I installed Python 3.3 64bit to match the bundled python of SublimeText 3 (Build 3083) and it finally worked. This is from within a REPL tab in Sublime Text:
Python 3.3.5 (v3.3.5:62cf4e77f785, Mar 9 2014, 10:35:05) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib.request
>>>
Related
I have 32-bit Python2.7 already installed in Windows 7 (64-bit Operating System) and I can use it without any errors. Besides, I attempted to install 64-bit Python3.4 and PyQt5 in the same Windows 7.
I followed the steps given in this link: Verify PyQt5 Packages Installed. I have installed 64-bit versions of Python3.4 and PyQt5. As mentioned in the given link, in order to verify the installation when I typed: from PyQt5 import QtCore, QtGui, QtWidgets I got this error:
ImportError: DLL load failed: %1 is not a valid Win32 application.
Is it possible that 32-bit Python2.7 causes this error message?
How can I fix this problem?
Thanks in advance!
Too complex situation. You have 64-bit Windows, which can install both 64 and 32-bit software. So you can install both 2.x and 3.x in both variants. For each Python installation, there could be 4 type of PyQt available, 4 & 5, both in 32 and 64-bit version. So the possibility of error is 2 * 4 * 4 * 2 = 64 times complex. Jokes apart.
Let's look at the error:
ImportError: DLL load failed: %1 is not a valid Win32 application.
Let's break it down:
ImportError: Nature of error we are getting is Import related. Python is not able to load specified module(s). Let's move forward.
DLL load failed: This message more or less says that module was in form of .dll file.
%1 is not a valid Win32 application. This error has most of the info. %1, which is more like an argument representing PyQt5, is not a valid Win32 application.
By looking at the error, it can be seen that interpreter looking for a Win32 application, which simply means a 32-bit application. But why would interpreter want a 32-bit module? Guess? Because interpreter itself is 32-bit!
It can't yet be said that it is Python3 or Python2 interpreter because error only specifies 32 or 64-bit information. But in your case it's your Python 2 interpreter because it's only the 32-bit interpreter on your system.
I have found online 2 commands that load a file and convert it in another format; the next step is to run a script for all the files in a folder.
Althought these commands require bpy, which I can't import.
I did install python 3.4 and the latest blender for Windows. Why Python can't find the bpy library? I am used to work with pip on unix systems, and this is my first attempt at using python on windows.
In the worst case I will just use linux via VM, but since I am running on windows; I would rather find out how you work with bpy.
UPDATE:
I did check the similar topic related to errors when importing bpy; in that case the module is not present, while in my case I can see the module in the Blender scripts folder.
I did copy the scripts to the Python3.4 folder, and when I run the import statement now it can see it but complains about the fact that there is no _bpy module. Not sure if there is a python version issue or some other problem.
Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:15:05) [MSC v.1600 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import bpy
Traceback (most recent call last):
File "<pyshell#0>", line 1, in <module>
import bpy
File "C:\Python34\Scripts\bpy\__init__.py", line 38, in <module>
from _bpy import types, props, app, data, context
ImportError: No module named '_bpy'
Blender as a python module is only available if you build blender from source yourself, normally the bpy module is only a part of the blender binary and is not available separately with any official blender releases. At this stage I don't know of any third parties that have made a bpy module available to download.
There are several ways you can use the bpy module within blender -
within a running copy of blender - blender includes a python console that can be used like a normal python interpreter, it also includes a simple text editor that has the option to run the text block as a python script.
run the script in blender from the cli - you can tell blender to run in the background (without the gui) and to run a python script.
blender -b --python myscript.py
it is also possible use blender as a python interpreter
blender -b --python-console
By default using blender as a python interpreter will only provide access to the reduced module list that blender includes with it's distributions. You can manually install python modules into the blender installed python to have them available. It is also possible to adjust the paths that python searches for modules. If you build blender yourself there is an option to use the system python instead of a local copy, you should also be able to delete (or move) the python libraries included with blender and have it find the system installed version, be careful to use matching versions.
As a heads up, this question may appear to be a duplicate of
embedding python module error
Embedding Python 3 - no builtins?
but I think my issue is different. I'm running a Python 3.4 interpreter from an MSVC compiled C++ application, and I'm trying to use the ptvsd module to make debugging easier. So far I've been able to attach to python interpeters that I start from the command line without issue, but I'd like to attach to a python interpreter embedded in my C++ application. To do this, I've been following the advice of
https://github.com/Microsoft/PTVS/wiki/Cross-Platform-Remote-Debugging
and
http://blogs.msdn.com/b/cdndevs/archive/2014/10/16/part-5-get-started-with-python-debugging-in-ptvs.aspx
The ptvsd module imports the _socket module, which I can clearly see in C:/Python34/DLLs. If I invoke python34.exe from the command line and run
import ptvsd
ptvsd.enable_attach(None)
I can find and attach to the process by looking at tcp://localhost:5678.
However, if I call
PyRun_SimpleString("import ptvsd");
from C++, I get an error saying that the _socket module could not be found. The same seems to be true for importing any of the builtin python modules into my C++ application, although I am able to import them correctly from a command line invoked python interpreter.
I am able to execute
PyRun_SimpleString("import sys \n print(sys.path)");
from my C++ application, and the result does show C:/Python34/DLLs, where the _socket.pyd file is located. But for some reason I'm unable to pick it up when I try and import it, or import ptvsd
Following the advice of Embedding Python 3 - no builtins?, I ran
PyObject* pGlobals = PyDict_New();
PyRun_String("import ptvsd", Py_file_input, pGlobals, pGlobals);
PyRun_String("ptvsd.enable_attach(None)", Py_file_input, pGlobals, pGlobals);
Which is a command that I truly don't understand. It actually made the error about _socket not being found vanish, but I think it just suppressed it. Calling
dir(ptvsd)
from python does display its functionality, but calling
PyRun_SimpleString("print(dir(ptvsd))");
does not. The first SO link I posted deals with a hand built module that couldn't be picked up by the interpeter, but that's not the case here. The module lives in a place that PYTHONPATH can find it, and it gets picked up by the command line fine (it also gets picked up by the Python Tools for Visual Studio IDE, but that's beside the point.)
I'm unable to check python2.7 on windows, but on linux python (2 and 3) had no trouble importing the _socket module from the c++ interpreter, so I'm hoping that it's just an environment issue.
Additionally, the output of
print(sys.version)
is
3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:43:06) [MSC v.1600 32 bit (Intel)]
from the command line, and
3.4.3 (default, Aug 29 2015, 22:43:06) [MSC v.1800 32 bit (Intel)]
from my C++ interpreter.
Sorry for all that, but does anyone understand what's going wrong? I'm sure there are some other hoops I need to go through to get things to work, but I don't know what they are yet...
For what it's worth, I'm able to import sys and math just fine. I'm also able to import a custom module I compile via
PyImport_AppendInittab(ModuleName.c_str(), _Mod_Init);
And I've tried all my tests with and without the above call.
Thank you for your time.
John
I'm trying to run some code from here:http://code.activestate.com/recipes/577654-dde-client/
On my Windows machine, using Python 2.7.8 via x86_64 Cygwin
I keep getting:
ImportError: cannot import name WINFUNCTYPE
>>> from ctypes import WINFUNCTYPE
It appears that I am missing a standard library from somewhere with this and probably other functions... But I cannot figure out how to get this library or from where? I do not have a lot of experience with python, especially not with importing native libraries... Is there like a cpan perl install module type mechanism or... How can I update this to get my code to work?
Most likely you started Cygwin's Python (by simply typing python in the Cygwin console) and not the one you want (Cygwin comes with Python in /usr/bin). You can test that by typing in the Python console:
import sys
sys.platform
It will output cygwin instead of win32. To launch the correct Python, you must specify the full path cygwinified (meaning that if your python is installed under "C:\dir1\Dir 2\python.exe", you'll have to type /cygdrive/c/dir1/Dir\ 2/python.exe).
I installed Python 3.1 and the Pygame module for Python 3.1. When I type import python in the console I get the following error:
Traceback (most recent call last):
File "<pyshell#2>", line 1, in <module>
import pygame
File "C:\Python31\lib\site-packages\pygame\__init__.py", line 95, in <module>
from pygame.base import *
ImportError: DLL load failed: %1 is not a valid Win32 application.
It could be due to the architecture of your OS. Is your OS 64 Bit and have you installed 64 bit version of Python? It may help to install both 32 bit version Python 3.1 and Pygame, which is available officially only in 32 bit and you won't face this problem.
I see that 64 bit pygame is maintained here, you might also want to try uninstalling Pygame only and install the 64 bit version on your existing python3.1, if not choose go for both 32-bit version.
Looks like the question has been long ago answered but the solution did not work for me. When I was getting that error, I was able to fix the problem by downloading PyWin32
I had installed Python 32 bit version and psycopg2 64 bit version to get this problem. I installed psycopg2 32 bit version and then it worked.
Had this issue on Python 2.7.9, solved by updating to Python 2.7.10 (unreleased when this question was asked and answered).
Another possible cause of similar issue could be wrong processorArchitecture in the cx_freeze manifest, trying to load x86 common controls dll in x64 process - should be fixed by this patch:
https://bitbucket.org/anthony_tuininga/cx_freeze/pull-request/71/changed-x86-in-windows-manifest-to/diff