I'm trying to enable IPv6 in a Python 2 application and am running into trouble. Whenever I try to bind to an IPv6 socket, a socket.error: getsockaddrarg: bad family exception is thrown. I can reproduce the error simply by doing:
import socket
s = socket.socket(socket.AF_INET6, socket.SOCK_STREAM)
s.bind(('', 12345))
This code works fine if I run in Python 3. Unfortunately the script would need a significant porting effort to work in Python 3 and I'd rather not have to do that yet.
Is there something I need to do to get IPv6 working in Python 2 or am I S-O-L?
Details:
Python 2.6.2 (r262:71600, Oct 24 2009, 03:16:31)
[GCC 4.4.1 [gcc-4_4-branch revision 150839]] on linux2
(it's the Python that's part of the standard openSUSE 11.2 install).
Update
After AndiDog helped me figure out that socket.AF_INET6 is defined even when IPv6 is not configured, I discovered socket.has_ipv6. This is defined as a boolean and indicates whether Python was build with IPv6.
Okay here's the answer from the comments:
Seems like Python wasn't configured with --enable-ipv6.
It shouldn't be a OS problem because Python 3 works. Even if the OS doesn't have IPv6 support, it seems that socket.AF_INET6 is always available (if it is defined in the OS header files). Cf. socketmodule.c, line 4433 (in current Python 2.6.4 source code).
Sounds like that particular Python was not compiled with IPv6 support.
In which case, you can download the source for that version and build yourself a compatible Python that will work. You may even be able to do some editing in the Debian package and upgrade the system python.
Works fine with 2.6.4 on my Mac (Mac OS X 10.5.8) -- and unfortunately I can't downgrade to 2.6.2 nor do I have any openSUSE around to check where the bug specifically comes from you. Could you try getting 2.6.4 and building from sources to see if the bug goes away, or check some openSUSE-specific bug tracker...? At least we do know it's not a generic Python 2.6 bug (with the latest, bug-fixed version of 2.6, at least)...
Related
I am quite puzzled by the following situation: a colleague and I both use Mac OS X. I use 10.15.3, python 2.7.15, GCC 4.2.1, cx_Oracle 7.0.0 with the SQL Developer 19.1.0. She uses 10.14.6, python 2.7.10, GCC 4.2.1, cx_Oracle 7.3.0 with the SQL Developer 18.3.0.
We have a simple python script that connects to a data base via cx_Oracle. We got the usual DPI-1047 error. I followed the instructions here https://oracle.github.io/odpi/doc/installation.html#macos and with the latest 19 "Basic" version, and a bit of tweaking because of the notarization (https://github.com/oracle/python-cx_Oracle/issues/341#issuecomment-541794557) I could make it work: the .dylib files are properly picked up and the code can connect to the db.
For my colleague, the file cannot be found. We followed the exact same steps as for my computer, downloaded first the 19 then the 18 "Basic" version (naively thinking it would be related to the SQL Developer version), unzipped, and added the link to the $LD_LIBRARY_PATH variable. However, the DPI-1047 error remains to pop up.
We tried to follow previous solutions in this or other forums, but they wouldn't apply or work for us:
https://github.com/oracle/python-cx_Oracle/issues/210 (with https://www.oracle.com/database/technologies/instant-client/linux-x86-64-downloads.html#ic_x64_inst) -> the same for us except the "per step 3" part does not apply -> we do not have any .so files in the instantclient download
DPI-1047: 64-bit Oracle Client library cannot be loaded - we verified that we both use 64-bit python using python -c 'import sys;print("%x" % sys.maxsize, sys.maxsize > 2**32)', rest in this thread applies to Windows
How to fix: cx_Oracle.DatabaseError: DPI-1047: Cannot locate a 64-bit Oracle Client library - Python - there is no /usr/lib/oracle folder, neither for me nor for her, where one would need to set the version explicitly; in fact, the downloaded folder contains a soft link to the proper version of the .dylib already (we also played around with having it point to other .dylib versions)
Thank you for your help!
c.
In summary you have an issue on the 10.14.6 (Mojave) computer.
My initial thought was that you are using the OS default Python. This won't work because Apple has locked it down. From the install instructions: "Make sure you are not using the bundled Python. This has restricted entitlements and will fail to load Oracle client libraries." (I have not/cannot venture into hacking Instant Client to see if it can be made to work)
However, where did Python 2.7.10 come from? My system default is Python 2.7.16.
Don't set LD_LIBRARY_PATH. Instead my ~/lib directory has just one symbolic link:
libclntsh.dylib -> /Users/cjones/instantclient_19_3/libclntsh.dylib
All the configuration issues are due to Apple's ever tightening security requirements. Hopefully the next Oracle Instant Client release will make it easier to use.
SQL Developer is almost completely unrelated to Python cx_Oracle usage (unless you use thick-JDBC connections in SQL Developer, which is rare).
And don't follow Linux or Windows instructions on macOS!
I installed python 2.7 and scapy following the supported programs: pywin32, WinPcap, Pypcap and libdnet. I feel that it is important to say that my OS is windows 7.
When I am using the function sniff it appears to raise an error: http://prntscr.com/dbd79a. I have tried another scapy's function and classes as IP and sendp and it works fine, the problem is only on sniff.
I have tried several versions of scapy from many installations links and no change.
Your problem is a bug in version 2.3.3 of scapy (uploaded on 18/10/16).
It will probably be fixed in the next version, in the meantime you can install the previous version by doing
pip install scapy==2.3.2
I checked in the commits and this bug wasnt in that version. However i havent tested it so it might contain other bugs (as 2.3.3 must have changed something for the better, atleast i hope it did), so if you must use 2.3.3 for some reason you can patch it around like this:
from scapy.arch.windows import compatibility
from scapy.all import log_runtime, MTU, ETH_P_ALL, PcapTimeoutElapsed, plist
compatibility.log_runtime = log_runtime
compatibility.MTU = MTU
compatibility.PcapTimeoutElapsed = PcapTimeoutElapsed
compatibility.ETH_P_ALL = ETH_P_ALL
compatibility.plist = plist
compatibility.sniff(1) # call the sniff function however you like
Python has a win32service package that seems to allow windows service creation. I have carefully checked available google examples, for example this one:
Is it possible to run a Python script as a service in Windows? If possible, how?
I have placed code into ~/Documents/test.py and executed following under elevated command prompt:
> python test.py install
> python test.py debug
Unfortunately, every example i tried fails with error:
Debugging service TestService - press Ctrl+C to stop.
Error 0xC0000005 - Python could find the service class in the module
AttributeError: 'module' object has no attribute 'AppServerSvc'
(null): (null)
I have tested it with latest version of ActivePython (2.7.2.5 32-bit) on Windows 7 64-bit and Windows 8 64-bit. Of course, if service is started maually via service manager, it will not start either.
Am i doing something wrong or Python is not intended to be used for service creation on modern operating systems? Maybe i need a specific version of windows/python/pywin32? Of course, i can manually test all combinations starting from windows XP but it will take lots of time :(. Maybe someone already has experience with Python and windows services and can hint me what i'm doing wrong?
update
Tested on Windows XP 32-bit virtual macine (same code, same activepython distribution) - same error.
It appears that there is a bug in the ActiveState build for PyWin32. Installing ActiveState python 2.7.2.5 and running the linked sample code above, I get the same error that you are reporting.
But if I download Python 2.7.3 (2.7.2.5 does not seem to be available for download) and add PyWin32 build 214 (ActiveState seems to be using the 214 version of PyWin32). Then everything seems to work just fine. I also tried the latest build of PyWin32 (218) and it also worked correctly.
So I guess you can try reporting the problem to ActiveState (I don't have a support contract with them) and unless you have a requirement for using ActiveState, you can just switch to the standard Python builds.
I have been using services with the standard Python builds for years running on everything from Windows 2000 up to Server 2008 and Windows 7 with no problems. So I have good reason to believe that it will work for you also.
If you want to work with ActiveState to get the problem fixed, then the bug appears to be in their build of PythonService.cpp in the LoadPythonServiceInstance function. I looked at the registry entries that were created and they look fine, it is the PythonService.exe that is failing at loading your class. Based on the error message it appears to have loaded the module correctly and is just having trouble finding the class.
Being quite cavalier I went for the latest version of Python (3.2.2)
Unfortunately it lacks the matplotlib that I desperately need.
I have downloaded python 2.7.
My simple question is weather I have to uninstall python3.2 or can I leave it on my windows 64 system?
you can keep the python 3.2 installation, but you will have to be carefull about which version you launch (by making the call explicit). you can always check the python version in a script by doing:
import sys
print sys.version
If you have no particular use of python 3.2, I recommend uninstalling it.
I'm not sure if there's a difference on python in windows but on mac and linux I simply call older versions using
python2.6 or python2.7
It seems to keep all the versions I previously had before. Maybe try running the above command and seeing if it works on windows and if it does just change the symbolic link 'python' is pointing to.
I am trying to get Netbeans python to run with the default python platform set to Python 2.6.1 (my system python), so in Netbeans I do the following:
Tools -> Python Platform
Set Python 2.6.1 to 'default'
However, it seems impossible to make this stick. Whenever I restart Netbeans it's back to Jython 2.5 again.
Moreover, I can obviously autodetect and find Python 2.6.1, but whenever I make it "Default", Netbeans still runs with Jython 2.5 in that very session. (I know this because when I import sys and do a sys.path it only has Jython library dirs). And when I remove Jython I get the error:
"Selected project has broken python platform : default => bind to an existing python platform in project's properties".
I have tried this is 6.5 and 6.7. And I still get the same behavior. Furthermore, I know my system python works because I can use the python interpreter.
Looks like http://netbeans.org/bugzilla/show_bug.cgi?id=180693 which provides a clumsy and non persistent workaround.
This needs heavy complaining on the netbean bug tracker imo.
Might be worth logging a bug with Netbeans about the first bit of behaviour you described - I can confirm similar (although strangely not identical) symptoms on my system.
I tried this with Python 2.6.2 / Netbeans 6.5.1
NetBeans IDE 6.5.1 (Build 200903060201)
Java: 1.6.0_01; Java HotSpot(TM) Client VM 1.6.0_01-b06
System: Windows XP version 5.1 running on x86; Cp1252; en_GB (nb)
And my default Python platform also doesn't seem to stick: I restart and the default is back to "Jython 2.5b0+"
However, when I create a new Python project: the drop-down on the wizard is correctly set to 'Python 2.6.2": furthermore, when I created a new module like this:
import sys
print(sys.path)
It reports back correctly:
...'d:\\python26\\DLLs', 'd:\\python26\\lib'...
Maybe this is due to something about the slightly different Python platform versions - dunno?