I'm trying to have my Python application interface with an NFC device via USB.
The best option seems to be PyUSB, but I can't get it to connect to the libusb backend.
I keep getting
ValueError: No backend available
I've looked at the stack trace, and found that usb/backend/libusb10.py (which is part of pyusb) is trying to load libusb-1.0.dll to use as the backend, but it can't find it. It's not that it's not in my path, it's not on my computer at all!
I have installed libusb-win32, but the resulting directory only seems to include libusb0.dll. Where is libusb-1.0.dll???!
I would love to know either where to get that dll, or even a different suggestion to get PyUSB to work on Windows 7.
Download and install libusb-win32-devel-filter-1.2.6.0.exe. It should work.
2021 and the problem still occurs on Windows (Windows 10). I solved it by installing pyusb and libusb and adding libusb path to Windows environment:
pip install pyusb
pip install libusb
libusb-1.0.dll will be automatically added to:
\venv\Lib\site-packages\libusb\_platform\_windows\x64
and
\venv\Lib\site-packages\libusb\_platform\_windows\x32
Now just add those paths (the full path) to Windows Path and restart CMD / PyCharm.
I had a similar issue recently trying to talk to a USB device I am developing. I scoured the web looking for libusb-1.0.dll's and had no luck. I found source code, but nothing built and ready to install. I ended up installing the libusb-win32 binaries, which is the libusb0.dll.
PyUSB will search for libusb-1.0, libusb0, and openUSB backends.
libusb0.dll was already on my system, but something was still not set up right, do PyUSB was not working.
I followed the directions here to download and install the driver using the GUI tools provided to install the filter driver, and the INF wizard. Note, it didn't work until I ran the INF wizard.
I'm pretty new to programming and I've found the lack of clear documentation/examples to string this all together rather frustrating.
I am using Python 2.6.5, libusb-win32-device.bin-0.1.12.1 and pyusb-1.0.0-a0 on a windows XP system and kept receiving ValueError: No backend available.
Since there wasn't any real help on the web for this problem I spent a lot of time finding that ctypes util.py uses the Path variable to find the library file. My path did not include windows\system32 and PYUSB didn't find the library. I updated the path variable and now the USB is working.
There's a simpler solution.
Download and unpack to C:\PATH the libusb-1.0.20 from download link
Then try this line:
backend = usb.backend.libusb1.get_backend(find_library=lambda x: "C:\PATH\libusb-1.0.20\MS32\dll\libusb-1.0.dll")
dev = usb.core.find(backend=backend, find_all=True)
Depending on your system, try either MS64 or MS32 version of the .dll
Update of 17/01/2020, after a request to share more code:
import usb.core
import usb.util
from infi.devicemanager import DeviceManager
dm = DeviceManager()
devices = dm.all_devices
for i in devices:
try:
print ('{} : address: {}, bus: {}, location: {}'.format(i.friendly_name, i.address, i.bus_number, i.location))
except Exception:
pass
import usb.backend.libusb1
backend = usb.backend.libusb1.get_backend(find_library=lambda x: "C:\\libusb-1.0.20\\MS32\\dll\\libusb-1.0.dll")
dev = usb.core.find(backend=backend, find_all=True)
def EnumerateUSB(): #I use a simple function that scans all known USB connections and saves their info in the file
with open("EnumerateUSBLog.txt", "w") as wf:
counter = 0
for d in dev:
try:
wf.write("USB Device number " + str(counter) + ":" + "\n")
wf.write(d._get_full_descriptor_str() + "\n")
wf.write(d.get_active_configuration() + "\n")
wf.write("\n")
counter += 1
except NotImplementedError:
wf.write("Device number " + str(counter) + "is busy." + "\n")
wf.write("\n")
counter += 1
except usb.core.USBError:
wf.write("Device number " + str(counter) + " is either disconnected or not found." + "\n")
wf.write("\n")
counter += 1
wf.close()
I had the same problem with Windows 10, both Python 2.7.16 and Python 3.7.2. I installed libusb (through python -m pip install libusb ) but the error message remained. Also, the advice above about installing libusb-win32 did not work for me; neither of the 2 links (original post and #beebek's answer) existed.
What did work, however, is the comment by #user1495323 : I copied libusb-1.0.dll from
C:\Users\username\AppData\Roaming\Python\Python27\site-packages\libusb\_platform\_windows\x64\
to C:\Windows\System32\
download the latest libusb
Download libusb
Copy MS32\dll\libusb-1.0.dll to C:\Windows\SysWOW64
Copy MS64\dll\libusb-1.0.dll to C:\Windows\System32
3.
pip install libusb
Copy MS32\dll\libusb-1.0.dll to C:\Python\Python37-32\Lib\site-packages\libusb_platform_windows\x86
Copy MS64\dll\libusb-1.0.dll to C:\Python\Python37-32\Lib\site-packages\libusb_platform_windows\x64
This method works for me.
Had some problems with backendnotavailable at 2022 when I install pyusb and libusb on my Windows x64.
I've found a way to solve it reading -> Github solve explaining
To solve, first you need copy path to libusb-1.0.dll (..\envs<your_env_name>\Lib\site-packages\libusb_platform_windows\x64) at system's PATH variable.
Secondly restart IDE.
Third try to get_backend use usb.backend:
import usb.core
from usb.backend import libusb1
# it should find libusb-1.0.dll at our path variable
back = libusb1.get_backend()
print(type(back)) # return: <class 'usb.backend.libusb1._LibUSB'>
dev = usb.core.find(backend=back)
print(type(dev)) # return: <class 'usb.core.Device'>
# flag 'find_all=True' would return generator
# reprecent connected usb devices
dev_list = usb.core.find(find_all=True, backend=back)
print(type(dev_list)) # return: <class 'generator'>
If back is a NoneType, that means get_backend() hasn't found libusb-1.0.dll or found the wrong usblib (and that was my problem - I copied atPATH variable path to _x86 file, on my x64 machine).
Another way to solve it -> copy libusb-1.0.dll from (.._x64\libusb-1.0.dll) to (C:\Windows\System32).
"There are two versions of the libusb API: the current libusb-1.0 API, and its legacy predecessor libusb-0.1." (http://www.libusb.org/) "libusb-win32 is a port of the USB library libusb-0.1 to the Microsoft Windows operating systems". "Download the latest release tarball" from the same page (1.0.9 is the current version) to have libusb-1.0 equivalent, you'll find a folder Win32, where you'll find your libusb-1.0.dll to play with! You can even build it: http://www.libusb.org/wiki/windows_backend.
EDIT
You have to build it (download from/ http://sourceforge.net/projects/libusb/files/libusb-1.0/) since the tarball is from 2012, while the latest sources are from 2014-06-15.
To connect to your NFC device via USB using PYUSB, you will need to install the backend for that device. I do not think there is any backend for any device other than a libusb device.
To build a backend. You will need to know the driver (.sys file) for your device, so you could write a wrapper DLL to expose functionalities in the device. Your DLL would have to have a method to find device based on PID & VID, another method to open device and another method to send data and so on...
Just in case:
I haven't tried this on Windows but I had to set DYLD_LIBRARY_PATH path to circumvent this error on the Macintosh.
export DYLD_LIBRARY_PATH=/opt/local/lib
Discussion on whether or not to set this variable is here.
The libusb backend is initialized by the python script in /usb path,by loading the binary DLL from Windows PATH,if it's missed or installed by the zadig's dummy DLL,it will complained about this.Because the DLL installed by zadig doesn't exports any symbol to outside wolrd(dummy one I guess)
Related
ahk code:
ComObjCreate("{C2474B5A-5E9D-484D-BDFD-20A100183426}")
this works in AutoHotkeyU32.exe, but not in AutoHotkeyU64.exe
error message is: the specified module could not be found.
full code is here: How to program hotstrings in python like in autohotkey
I call my SymPy functions using ahk hotkeys. I register the python script as a COM server using pywin32 and load it using ahk.
you'll need pywin32, but don't download using pip install pywin32
download from https://github.com/mhammond/pywin32/releases
OR ELSE IT WON'T WORK for AutoHotkeyU64.exe, it will only work for AutoHotkeyU32.exe.
make sure to download amd64, (I downloaded pywin32-300.win-amd64-py3.8.exe)
EDIT: now I understand why it didn't work
I think it CAN work when using pip install pywin32 if you register it correctly.
you have 2 choices:
register it correctly as shown here How to program hotstrings in python like in autohotkey :
do NOT use UseCommandLine(), use RegisterServer(clsctx=pythoncom.CLSCTX_LOCAL_SERVER, ...)
after server has been registed using UseCommandLine(), delete the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{C70F3BF7-2947-4F87-B31E-9F5B8B13D24F}\PythonCOMPath\InprocServer32
replace {C70F3BF7-2947-4F87-B31E-9F5B8B13D24F} with your own CLSID
(I think) there is no need for
key: InprocServer32:
Name : (Default)
Type : REG_EXPAND_SZ
Data : pythoncom39.dll,
also, requiring it makes it fail
(I think) There's no need because it actually uses LocalServer32 (which is also a key)
mine is:
Name : (Default)
Type : REG_SZ
Data : C:\PROGRA~3\Miniconda3\pythonw.exe "C:\ProgramData\Miniconda3\lib\site-packages\win32com\server\localserver.py" {C70F3BF7-2947-4F87-B31E-9F5B8B13D24F}
localserver.py is the one doing the COM stuff, to prove it, replace pythonw with python. you will the window when it's ran.
I was playing around with the Scapy sniff function and I wanted to add a filter into the parameters. So I added this filter:
pkt = sniff(count=1, filter='arp')
and the output i recieve is:
WARNING: Cannot set filter: libpcap is not available. Cannot compile filter !
I still get a packet that was sniffed, but for some reason the filter is not working.
I am running Mac OS Big Sur. I have libpcap installed using Homebrew and I have tcpdump installed using Homebrew.
I also saw online that you could manually initialize pcap on Scapy using
conf.use_pcap = True
However when I type this in I get:
WARNING: No libpcap provider available ! pcap won't be used
I'm sure it is just a small fix but I can't seem to figure out what I am doing wrong. If anyone can help that would be amazing!
Older versions of Python 3 assume that, on macOS, all shared libraries are in files located in one of a number of directories.
That is not the case in Big Sur; instead, a cache file is generated for system shared libraries, and at least some of the libraries from which the cache file is generated are not shipped with the OS.
This is one of the issues in CPython issue 41100, "Support macOS 11 and Apple Silicon Macs"; the fix is to look in the shared library cache as well as in the file system.
That issue says
Thank you to everyone who contributed to this major undertaking! A particular thank you to Lawrence for doing much of the initial work and paving the way. Now that 3.8 also supports Big Sur and Apple Silicon Macs as of the imminent 3.8.10 release, it's time to close this issue. If new concerns arise, pleasa open or use other issues.
So a sufficiently recent version of Python should fix this issue.
tldr:
$ brew install libpcap
$ ln -s /usr/local/opt/libpcap/lib/libpcap.a /usr/local/lib/libpcap.a
$ ln -s /usr/local/opt/libpcap/lib/libpcap.dylib /usr/local/lib/libpcap.dylib
Explanation (applicable for Python 3.9.1, Scapy 2.4.5 # Big Sur and libpcap installed by brew):
When you debug the Scapy sniff function, after a while you get to scapy.libs.winpcapy, line 36:
_lib_name = find_library("pcap")
find_library is located in ctypes.util, for POSIX it starts on line 72. On line 73 you can see that the library is expected as one of these filenames ['libpcap.dylib', 'pcap.dylib', 'pcap.framework/pcap'], being fed to dyld_find.
dyld_find is located in ctypes.macholib.dyld on line 121. If you iter through the chain on line 125 yourself, you find out that dyld_find is trying to succeed with one of these paths:
/usr/local/lib/
/Users/<user>/lib/
/usr/local/lib/
/lib/
/usr/lib/
In my case none of them contained the libpcap lib, which is installed in different location by brew.
The library sits in /usr/local/opt/libpcap/lib/.
And here you go, you just need to get the file libpcap.dylib (nothing wrong with libpcap.a too) into one of those paths searched by dyld_find. The two soft links above are one of a few more possible solutions.
Im trying to run Stockfish chess engine, but in the line that execute the binary give me this error:
Script:
import chess
import chess.uci
import chess.engine
fen = 'r2qkb1r/1p1bpp1p/p1n2p2/8/B1pP4/5N2/P1P2PPP/RN1QK2R w KQkq - 0 12'
board = chess.Board(fen)
handler = chess.uci.InfoHandler()
engine = chess.uci.popen_engine('/home/egqbe6ns/public_html/stockfish_10_x64')
Error:
/home/egqbe6ns/public_html/stockfish_10_x64: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home/egqbe6ns/public_html/stockfish_10_x64)
/home/egqbe6ns/public_html/stockfish_10_x64: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by /home/egqbe6ns/public_html/stockfish_10_x64)
Im in a shared server, other python script execute ok!
How can I update this libc6 with PUTTY SSH?
How can I update this libc6 with PUTTY SSH?
You can't.
Your stockfish_10_x64 binary was built on a GLIBC-2.17 or later system, and will only run on a system with that version of GLIBC (or a later one).
The only (not completely true, see below) way to get this working is to update the GLIBC on the server, and if you don't have root on that server, you can't do that.
You would need to get a different build of stockfish_10_x64, or run on a different server.
P.S. You may be tempted to try LD_LIBRARY_PATH or LD_PRELOAD solutions, but they will not work.
P.P.S. Using explicit loader invocation with a newer GLIBC might work. Something like this:
install GLIBC-2.17 or later into /home/egqbe6ns/libc.
invoke stockfish_10_x64 like so:
/home/egqbe6ns/libc/lib/ld-linux-x86-64.so.2 --library-path=/home/egqbe6ns/libc/lib64:/lib64 /home/egqbe6ns/public_html/stockfish_10_x64
Recently, I just try to connect my SQL Server in python. So I just download the .whl file from "http://www.lfd.uci.edu/~gohlke/pythonlibs/#pymssql".
in cmd windows, I use the following command:
pip install some-package.whl
My pc is window 64bit, I tried all the .whl files in the following.
http://www.lfd.uci.edu/~gohlke/pythonlibs/#pymssql
pymssql‑1.0.3‑cp27‑none‑win32.whl
pymssql‑2.1.3‑cp27‑cp27m‑win32.whl
pymssql‑2.1.3‑cp27‑cp27m‑win_amd64.whl
pymssql‑2.1.3‑cp34‑cp34m‑win32.whl
pymssql‑2.1.3‑cp34‑cp34m‑win_amd64.whl
pymssql‑2.1.3‑cp35‑cp35m‑win32.whl
pymssql‑2.1.3‑cp35‑cp35m‑win_amd64.whl
pymssql‑2.1.3‑cp36‑cp36m‑win32.whl
pymssql‑2.1.3‑cp36‑cp36m‑win_amd64.whl
But failed to install, with the error message, the .whl file is not supported in this system. what should I do. Can somebody help me.
The simplest procedure that helped me is:
Step 1: Open cmd as an administrator
Step 2: Type python and press Enter
You will get something like this
Here, you can see your Python version and the CPU Architecture
Step 3: Go on https://www.lfd.uci.edu/~gohlke/pythonlibs/#pymssql and select .whl file that support both, python version and also the CPU architecture. i.e. the supported file for me will be pymssql‑2.2.2‑cp39‑cp39‑win_amd64.whl where cp39 means the python version that is 3.9 in my case, and amd64 is the CPU architecture.
Step 4: Go the folder where you have downloaded the required file and in the address bar type cmd or you can open cmd as an admin and move to the download directory
Step 5: Copy name of the required downloaded file along with extension and Run the following command
pip install pymssql‑2.2.2‑cp39‑cp39‑win_amd64.whl
That's all. You can use this method for any file from this website. This method is working for me perfectly
I faced the same issue. It goes with version of Python installed on your system if it is 32 bit Python Version or 64 bit Python.
So cp36 as I have python 3.6 and win32 as Python is 32 bit according to my system.
I worked for me.
I hope this helps.
whl naming structure:
{distribution}-{version}(-{build tag})?-{python tag}-{abi
tag}-{platform tag}.whl
in your case you need to know your python --version (python tag cp27 for python2.7 etc) and your cpu architecture .
Faced the same issue,
All you need to do is change the name of your whl file:
Change up to the installed python distribution
Then none for the python version and any for the platform
Should be something like
pymssql‑2.1.3‑cp3‑none‑eny.whl
You can do this using packaging.
pip install packaging
You can use this simple function compatible_wheels I wrote using packaging to filter out for the compatible wheels for your system:
from packaging.tags import sys_tags
def parse_tag(wheel_filename):
"""
Example:
>>> parse_tag('pymssql-2.2.1-cp36-cp36m-manylinux2010_i686.whl')
'cp36-cp36m-manylinux2010_i686'
"""
return '-'.join(wheel_filename.split('-')[2:])[:-4]
def compatible_wheels(wheel_filenames):
tags = [str(tag) for tag in sys_tags()]
return [
f
for f in wheel_filenames
if parse_tag(f) in tags
]
Example usage
>>> wheel_filenames = [
'pymssql-2.2.1-cp36-cp36m-manylinux2010_i686.whl',
'pymssql-2.2.1-cp36-cp36m-manylinux2014_i686.whl',
'pymssql-2.2.1-cp37-cp37m-manylinux1_i686.whl',
'pymssql-2.2.1-cp39-cp39-manylinux2014_i686.whl',
'pymssql-2.2.1-cp37-cp37m-win32.whl',
'pymssql-2.2.1-cp36-cp36m-manylinux_2_24_x86_64.whl',
'pymssql-2.2.1-cp37-cp37m-manylinux2010_x86_64.whl',
'pymssql-2.2.1-cp37-cp37m-manylinux2014_i686.whl',
'pymssql-2.2.1-cp38-cp38-manylinux2014_i686.whl',
'pymssql-2.2.1-cp36-cp36m-manylinux_2_24_i686.whl',
'pymssql-2.2.1-cp38-cp38-macosx_10_14_x86_64.whl',
'pymssql-2.2.1-cp38-cp38-manylinux2014_x86_64.whl',
'pymssql-2.2.1-cp38-cp38-win_amd64.whl',
'pymssql-2.2.1-cp39-cp39-win32.whl',
'pymssql-2.2.1-cp39-cp39-manylinux_2_24_x86_64.whl',
'pymssql-2.2.1-cp39-cp39-win_amd64.whl',
'pymssql-2.2.1-cp39-cp39-manylinux2014_x86_64.whl',
'pymssql-2.2.1-cp38-cp38-manylinux2010_x86_64.whl',
'pymssql-2.2.1-cp38-cp38-manylinux_2_24_x86_64.whl',
'pymssql-2.2.1-cp38-cp38-win32.whl',
'pymssql-2.2.1-cp39-cp39-manylinux2010_i686.whl',
'pymssql-2.2.1-cp39-cp39-manylinux_2_24_i686.whl',
'pymssql-2.2.1-cp37-cp37m-macosx_10_14_x86_64.whl',
'pymssql-2.2.1-cp37-cp37m-manylinux2010_i686.whl',
'pymssql-2.2.1-cp38-cp38-manylinux1_i686.whl',
'pymssql-2.2.1-cp38-cp38-manylinux_2_24_i686.whl',
'pymssql-2.2.1-cp37-cp37m-manylinux2014_x86_64.whl',
'pymssql-2.2.1-cp36-cp36m-manylinux2010_x86_64.whl',
'pymssql-2.2.1-cp39-cp39-manylinux1_x86_64.whl',
'pymssql-2.2.1-cp36-cp36m-manylinux1_x86_64.whl',
'pymssql-2.2.1-cp37-cp37m-manylinux1_x86_64.whl',
'pymssql-2.2.1-cp39-cp39-manylinux1_i686.whl',
'pymssql-2.2.1-cp36-cp36m-manylinux1_i686.whl',
'pymssql-2.2.1-cp36-cp36m-manylinux2014_x86_64.whl',
'pymssql-2.2.1-cp37-cp37m-manylinux_2_24_i686.whl',
'pymssql-2.2.1-cp37-cp37m-manylinux_2_24_x86_64.whl',
'pymssql-2.2.1-cp37-cp37m-win_amd64.whl',
'pymssql-2.2.1-cp38-cp38-manylinux2010_i686.whl',
'pymssql-2.2.1-cp38-cp38-manylinux1_x86_64.whl',
'pymssql-2.2.1-cp39-cp39-macosx_10_14_x86_64.whl',
'pymssql-2.2.1-cp39-cp39-manylinux2010_x86_64.whl',
]
>>> compatible_wheels(wheel_filenames)
['pymssql-2.2.1-cp39-cp39-manylinux_2_24_x86_64.whl', 'pymssql-2.2.1-cp39-cp39-manylinux2014_x86_64.whl', 'pymssql-2.2.1-cp39-cp39-manylinux1_x86_64.whl', 'pymssql-2.2.1-cp39-cp39-manylinux2010_x86_64.whl']
# Note: I get the above output because I am using Linux. You may be getting the wheels for windows accordingly based on your system.
I have downloaded mysql-connector-python-1.0.7-py2.7.msi from MySQL site
and try to install but it gives error that
Python v2.7 not found. We only support Microsoft Windows Installer(MSI) from python.org.
I am using Official Python v 2.7.3 on windows XP SP3 with MySQL esssential5.1.66
Need Help ???
I met the similar problem under Windows 7 when installing mysql-connector-python-1.0.7-py2.7.msi and mysql-connector-python-1.0.7-py3.2.msi.
After changing from "Install only for yourself" to "Install for all users" when installing Python for windows, the "python 3.2 not found" problem disappear and mysql-connector-python-1.0.7-py3.2.msi was successfully installed.
I guess the problem is that mysql connector installer only looks for HKEY_LOCAL_MACHINE entries, and the things it looks for might be under HKEY_CURRENT_USER etc. So the solution that change the reg table directly also works.
The Solution I get for this problem is
I have found Adding Python to Registry, the script as follows applicable for python v 2.0 and above:
Register a Python Interpreter
#
# script to register Python 2.0 or later for use with win32all
# and other extensions that require Python registry settings
#
# written by Joakim Low for Secret Labs AB / PythonWare
#
# source:
# http://www.pythonware.com/products/works/articles/regpy20.htm
import sys
from _winreg import *
# tweak as necessary
version = sys.version[:3]
installpath = sys.prefix
regpath = "SOFTWARE\\Python\\Pythoncore\\%s\\" % (version)
installkey = "InstallPath"
pythonkey = "PythonPath"
pythonpath = "%s;%s\\Lib\\;%s\\DLLs\\" % (
installpath, installpath, installpath)
def RegisterPy():
try:
reg = OpenKey(HKEY_LOCAL_MACHINE, regpath)
except EnvironmentError:
try:
reg = CreateKey(HKEY_LOCAL_MACHINE, regpath)
SetValue(reg, installkey, REG_SZ, installpath)
SetValue(reg, pythonkey, REG_SZ, pythonpath)
CloseKey(reg)
except:
print "*** Unable to register!"
return
print "--- Python", version, "is now registered!"
return
if (QueryValue(reg, installkey) == installpath and
QueryValue(reg, pythonkey) == pythonpath):
CloseKey(reg)
print "=== Python", version, "is already registered!"
return
CloseKey(reg)
print "*** Unable to register!"
print "*** You probably have another Python installation!"
if __name__ == "__main__":
RegisterPy()
Save it with any name.
Run it from python interpreter and Thats ALL!!
This problem mainly comes with 64 bit windows. download MySQL for python 64 bit on this link http://www.codegood.com/archives/129 and download MySQL-python-1.2.3.win-amd64-py2.7.exe (1.0 MiB)
This will install MySQL for python.
Windows 10 (64bit):
Indeed, I've had a similar issue and couldn't install the python 2.7 connector for MySQL.
Prior to this I've installed Python 2.7.15 with the Windows x86-64 MSI installer,
this was while I had Python 3 installed on my machine.
The Windows x86 MSI installer did the trick, I've installed it to override the previous version of Python 2.7.15, then installed the connector (this time it gave no error messages).
Then rechecked the status in the MySQL installer and voilà:
If you're still experiencing this with x64 or other python modules, I'd recommend this website Python Extensions for x64/x32
I had this problem because I use Python only from within SPSS. I resolved this problem by manually adding two registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\InstallPath
set to
C:\Program Files\IBM\SPSS\Statistics\24\Python
and
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\PythonPath
set to
C:\Program Files\IBM\SPSS\Statistics\24\Python\Lib
This easily fixed the issue on my previous as well as current laptops.
You need to make sure that you download the version with the correct "bitness" (32/64 bit), matching the "bitness" of your Python installation!
I ran into the same problem (with Python 3.7.2, though).
I had Python 3.7.2 32 bit already installed, but accidentally downloaded the 64 bit version of the MySQL Connector for Python 3.7.
When I tried to install the connector, I got the same error message:
Solution: I just downloaded the 32 bit version instead, and everything worked (installing the connector and actually connecting to the database)
In my case, I installed python 2.7.14 x64 only for my user. I have to look for this in my registry:
HKEY_CURRENT_USER\Software\Python
, export them, open the exported .reg file with a text editor, replace all occurrence of HKEY_CURRENT_USER with HKEY_LOCAL_MACHINE, and import it.
The result is: (remember to change the install dir to yours)
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Python]
[HKEY_LOCAL_MACHINE\Software\Python\PythonCore]
[HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.7]
[HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.7\Help]
[HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.7\Help\Main Python Documentation]
#="D:\\Desarrollo\\entornos\\python27_x64\\Doc\\python2714.chm"
[HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.7\InstallPath]
#="D:\\Desarrollo\\entornos\\python27_x64\\"
[HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.7\InstallPath\InstallGroup]
#="Python 2.7"
[HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.7\Modules]
[HKEY_LOCAL_MACHINE\Software\Python\PythonCore\2.7\PythonPath]
#="D:\\Desarrollo\\entornos\\python27_x64\\Lib;D:\\Desarrollo\\entornos\\python27_x64\\DLLs;D:\\Desarrollo\\entornos\\python27_x64\\Lib\\lib-tk"
And the installation afterwards is smooth as a breeze. Viola!
I solved this problem by using 32bit python