A SANE scanner backend written in Python?

[dwelch]

I've read many times on this newsgroup over the years that you can write
"just about anything" in Python, except perhaps a full operating system
(maybe even that...?). So, with this spirit in mind, I would like to try
to write a SANE scanner backend that I need to write, in Python rather
than C. This work is being done on Linux using Python 2.4.2.

If you are not familar with SANE, and the SANE API, it basically boils
down to supplying a libsane-<name of your backend>.so shared library
that supports a basic C interface. Example sane API calls into a backend
are: sane_init(), sane_open(), sane_start(), sane_read() and
sane_cancel(). At runtime, a backend is loaded up and its C interface is
called to determine what devices are supported by the backend, to set
options, and to actually perform a scan.

Obviously, this is an example of embedding Python, albiet with a
different end result. I have not found any examples in the wild that
embed Python in a shared library (vs. a standalone executable).

My trials so far have been fruitless. To start with, I simply took an
outline of a shared library that defined all the relevant SANE APIs,
linked it with SANE and Python, and placed a PyInitialize() in the
sane_init() function. This immediately results in a segmentation fault.
I'm not sure how to proceed from here. How would a separate .py file be
accessed in this way and how would I call "back" into Python code when a
C API was called? Is there going to be a problem of maintaining "state"
in Python between invocations of the C API?

I've also explored using Elmer for this task, but have not had luck so
far. Its also not clear to me whether this tool is appropriate for this
task.

So, what I'd be interested in knowing is whether this is a foolish
venture, or if I just have the wrong approach.

Any thoughts would be appreciated.

Thanks,

-Don

 

[Lonnie Princehouse]

Recompile Python and SANE with debugging enabled, if you haven't
already. That should allow you to trace back to the source of the error
using gdb (or your favorite gdb front-end). AFAIK there's no inherent
reason that embedding Python in a shared library wouldn't work. Did
you try compiling the outline of the shared library without the
PyInitialize call? Is it possible that the segfault had nothing to do
with python?