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.