We Keep Coding

Python can't locate .so shared library with ctypes.CDLL - Windows

I am trying to run a C function in Python. I followed examples online, and compiled the C source file into a .so shared library, and tried to pass it into the ctypes CDLL() initializer function.
import ctypes
cFile = ctypes.CDLL("libchess.so")
At this point python crashes with the message:
Could not find module 'C:\Users\user\PycharmProjects\project\libchess.so' (or one of its dependencies). Try using the full path with constructor syntax.
libchess.so is in the same directory as this Python file, so I don't see why there would be an issue finding it.
I read some stuff about how shared libraries might be hidden from later versions of python, but the suggested solutions I tried did not work. Most solutions were also referring to fixes involving linux system environment variables, but I'm on Windows.
Things I've tried that have not worked:
changing "libchess.so" to "./libchess.so" or the full path
using cdll.LoadLibrary() instead of CDLL() (apparently both do the same thing)
adding the parent directory to system PATH variable
putting os.add_dll_directory(os.getcwd()) in the code before trying to load the file
Any more suggestions are appreciated.

Solved:
Detailed explanation here: https://stackoverflow.com/a/64472088/16044321
The issue is specific to how Python performs a DLL/SO search on Windows. While the ctypes docs do not specify this, the CDLL() function requires the optional argument winmode=0 to work correctly on Windows when loading a .dll or .so. This issue is also specific to Python versions greater than 3.8.
Thus, simply changing the 2nd line to cFile = ctypes.CDLL("libchess.so", winmode=0) works as expected.

Why does python throw an undefined symbol error when importing a shared object from an alternate path?

I created a python extension using Boost::Python. To make it easier to use the extension on different target machines, I have included the libboost_python36.so.1.75.0 library in the same directory as the generated extension (pyshmringbuffer.so).
I checked out pyshmringbuffer.so and libboost_python36.so.1.75.0 onto a machine other than it was compiled in the directory : /path/to/pyshmringbuffer
After setting LD_LIBRARY_PATH to: /path/to/pyshmringbuffer and changing to this directory, I am able to run python3.6 and import the shared object just fine.
The problem comes when I try to run python from an alternate directory. From any other directory, I append the python path as follows:
import sys
sys.path.append("/path/to/pyshmringbuffer")
Then, when I try to import pyshmringbuffer, I get the following undefined symbol:
ImportError: /path/to/pyshmringbuffer/pyshmringbuffer.so: undefined symbol: _ZNK5boost6python7objects21py_function_impl_base9max_arityEv
I was under the impression that all symbols are self contained within the shared object. Why does it matter where I import the shared library from?

The symbol in your error message is an internal one, generated by one of the build tools. Having one undefined suggests that one of your components was built with an incompatible tool version, or that a *.so file (shared object) is out of date in some other fashion.
The simplest way to fix this is usually to rebuild your product components from scratch, in the proper order.

I was able to resolve my issue by prepending /path/to/pyshmringbuffer to my python path using:
sys.path.insert(0,"/path/to/pyshmringbuffer")
I can't say for sure, but as #PRUNE pointed out, there is something in my python path that python is seeing before it sees the intended library.
Coincidentally, I DO have a build of libboost_python36.so.1.75.0 located elsewhere on the target machine. The path for this doesn't appear on my PYTHONPATH or LD_LIBRARY_PATH, so I wouldn't EXPECT it to have been interfering, but I can't be positive.

How to build sphinx docs for micropython

How do I configure sphinx to document modules intended for a MicroPython interpreter?
The fundamental problem I'm facing is that sphinx gets the information it documents from the imported module. Therefore the python interpreter used to document a module must be importable into that interpreter.
First Problem
I'm using a pyboard, so naturally
import pyb
cannot find module pyb...
So I added to conf.py
from unittest.mock import MagicMock
sys.modules['pyb'] = MagicMock() # and many more
Second Problem
One of my MicroPython libraries is called cmd
Exception occurred:
File "/usr/lib/python3.5/pdb.py", line 135, in <module>
class Pdb(bdb.Bdb, cmd.Cmd):
AttributeError: module 'cmd' has no attribute 'Cmd'
So that makes sense... I changed the name of the module to ucmd, and that appears to be working... but it's suuuuuper dodgy.
Question
Is there a proper way to do this?
To sphinx document a module not designed for the platform running the sphinx-build command?
Phrased more practically: if I wanted to document a MicroPython module called collections, subprocess, or io (all of which are used by the sphinx library), is it possible to use sphinx to do so?
Or would I simply have to be content with naming them ucollections, usubprocess, and uio respectively?

Below is not a sphinx solution, but does provide for a partial autocompletion in most modern editors.
to generate stubs for a (custom) MicroPython module you could use the MicroPython-Stubber
for configuration for a custom module see section 4.4
Alternatively in that same repro in various tests I import the MicroPython-CPython stubs ( sourced from micropython-lib and pycopy-lib) by inserting that that in CPython's sys.path.
This works very well for my testing purposes, allowing me to run and debug (hardware agnostic) MicroPython code with no or little alteration on CPython.
Perhaps it suits your documentation needs as well.

error when calling the metaclass bases function() argument 1 must be code not str

I followed this to set up twilio: https://www.fullstackpython.com/blog/send-sms-text-messages-python.html
The imports seem to be working when I run locally using python send_sms.py
Then, I use Apache Nifi ExecuteScript processor to execute the send_sms.py file and assume it should be same as if I am running the file locally.
It shows me the error:
error when calling the metaclass bases function() argument 1 must be code not str
When I am trying to: from twilio.rest import TwilioRestClient.
Twilio was installed at path /sendsms/lib/python2.7/site-packages, so I set the Module Directory to this path
Does anyone know what is wrong here? I am really stuck and please help.

ExecuteScript uses Jython (not Python) to execute pure Python scripts, and as such any imported packages (and their dependencies) must be pure Python modules as well. I am guessing that TwilioRestClient (or its dependencies) include a non-pure Python module (compiled C, e.g.). For these cases, Jython (and thus ExecuteScript) will not work.
An alternative is to use the ExecuteStreamCommand processor, with which you can shell out to your Python interpreter (and script).

How to fix error "AttributeError: 'module' object has no attribute 'client' in python3?

The following is my code.
import http
h1 = http.client.HTTPConnection('www.bing.com')
I think it's ok.But python give me the following error:
AttributeError: 'module' object has no attribute 'client'.
I wanted to know why and how to fix it.Thanks.

First, importing a package doesn't automatically import all of its submodules.*
So try this:
import http.client
If that doesn't work, then most likely you've got a file named http.py, or a directory named http, somewhere else on your sys.path (most likely the current directory). You can check that pretty easily:
import http
http.__file__
That should give some directory like /usr/lib/python3.3/http/__init__.py or /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/http/__init__.py or something else that looks obviously system-y and stdlib-y; if you instead get /home/me/src/myproject/http.py, this is your problem. Fix it by renaming your module so it doesn't have the same name as a stdlib module you want to use.
If that's not the problem, then you may have a broken Python installation, or two Python installations that are confusing each other. The most common cause of this is that installing your second Python edited your PYTHONPATH environment variable, but your first Python is still the one that gets run when you just type python.
* But sometimes it does. It depends on the module. And sometimes you can't tell whether something is a package with non-module members (like http), or a module with submodules (os). Fortunately, it doesn't matter; it's always save to import os.path or import http.client, whether it's necessary or not.