What are you making from this Python error?
Here's a mistake.
Traceback (most recent call last):
File "_ctypes/callbacks.c", line 295, in 'calling callback function'
File "USB2.py", line 454, in ff
self.drv_locked = False
SystemError: Objects/cellobject.c:24: bad argument to internal function
Python code is used here.
def drv_send(self, data, size):
if not self.Connected():
return
def f():
self.drv_locked = True
buffer = ''.join(chr(c) for c in data[:size])
out_buffer = cast(buffer, POINTER(c_uint8))
request_handle = (OPENUSB_REQUEST_HANDLE * 1)()
request = (OPENUSB_INTR_REQUEST * 1)()
request_handle[0].dev = self.usbhandle
request_handle[0].interface = INTERFACE_ID
request_handle[0].endpoint = LIBUSB_ENDPOINT_OUT + 1
request_handle[0].type = USB_TYPE_INTERRUPT
request_handle[0].req.intr = request
def f(req):
print req[0].req.intr[0].result.status, req[0].req.intr[0].result.transferred_bytes
self.drv_locked = False # Line 454
request_handle[0].cb = REQUEST_CALLBACK(f)
request_handle[0].arg = None
request[0].payload = out_buffer
request[0].length = size
request[0].timeout = 5000
request[0].flags = 0
request[0].next = None
r = lib.openusb_xfer_aio(request_handle)
print "result", r
self.command_queue.put(f)
And this is where the Python source is involved.
PyObject *
PyCell_Get(PyObject *op)
{
if (!PyCell_Check(op)) {
PyErr_BadInternalCall(); // Line 24
return NULL;
}
Py_XINCREF(((PyCellObject*)op)->ob_ref);
return PyCell_GET(op);
}
source to share
An internal error is clearly a bug in Python itself, and if you are interested in exploring this further and suggesting a fix for the Python kernel, then simplifying your code to the point where it still throws an error is the right strategy.
If you are more interested in how your code works than in fixing the Python kernel, I suggest you avoid some of the anomalies in your code that can obfuscate Python. For example, I don't know if anyone has ever thought of checking a property for a named nested function f
containing another nested function also named f
- it SHOULD work, but it's exactly the kind of thing that might not have been are well tested just because no one has thought about it yet, and while deliberately provoking such anomalies is a very good strategy for strengthening the test suite, it is best avoided unless you intentionally run bugs in Python internals.
So first, I would make sure there is no homonymy around. If that still leaves an error, I would immediately remove the use of cell objects by converting what is currently accessing non-local variables into "pre-arguments", for example your "semi-outer" f
could be changed to start with: / p>
def f(self=self):
and your "completely internal" can become:
def g(req, self=self):
This will result in access to self
any of these functions (currently non-local variables) in local variables. Yes, you don't need to do this (there should be no bugs in any software that requires you to bypass them), but alas, perfection is not a characteristic of this sublunary world, so learning problematic bypass strategies is inevitably part of life; -).
source to share
The function PyCell_Check
checks that its argument is actually a cell object (an internal type used to implement variables referenced by multiple scopes). If op
it is not a cell object, you will get this error.
The code you posted does not provide enough context / information to determine exactly how the wrong parameter should have been passed.
source to share