www.neuron.yale.edu

Long ago I suggested the possibility of developing a Python interface for NEURON based on the built-in ctypes package. The main advantages would be:

1) it would no longer be necessary to compile the NEURON+Python bindings; instead Python would just directly access the NEURON shared library. This also means that NEURON could be made to work with any version of Python on any operating system, without having to provide precompiled binaries for that combination (or expect the user to compile it themselves).

2) The Python interface would be written in pure python which would make it much easier to develop (especially for folks like me who struggled to understand the C internals of NEURON). This might allow some of the rough edges in the Python API to be worked through more quickly.

The only requirement would be that NEURON provides an external C API. I spent some time poking at the code and never quite understood what was needed to make this happen.. My questions are: Is development of a C API still in the planning for NEURON, and if so, would there be interest in developing a pure-Python interface? I would be willing to put some effort toward the Python end, but only if the developers think this is a worthwhile goal.

If you're using NEURON 7.3 or higher, neuron.nrn_dll() returns a ctypes object corresponding to the NEURON library. The main difficulty here is that the C API exists only informally; there is no documentation or promise of what functions will have a stable interface, but you are encouraged to poke around to see what you can do.

Unfortunately, the current support for ctypes doesn't help with either of your objectives, but maybe it's a start. Are there any particular rough edges you have in mind?

ramcdougal wrote:Are there any particular rough edges you have in mind?

To be honest, it's been a few years since I looked, and many of the edges may have been polished over.
In general I just found the API a bit unpythonic and cumbersome to use. Examples:

- Some objects lack proper classes and simply appear as "hoc.HocObject"
- HocObjects may have attributes that do no appear when running dir(obj)
- A single NEURON object may be wrapped multiple times by different Python objects, making the expression "obj1 is obj2" meaningless
- Multiple namespaces nrn, neuron, neuron.h without obvious organization
- No context management (overuse of global variables)

Many of these are probably easily fixable, but consider that most Python users could dig into a pure-Python interface and contribute patches, whereas the barrier to contributing to the current Python interface is much higher.
More importantly, the barrier to using NEURON+Python at all is still high in some cases.