www.neuron.yale.edu

I have been working with Python + NEURON lately and found myself frustrated with the API on several occasions. Some of the problems are related to the original translation from HOC to Python, some are historical API issues inherited from early versions of the Python interface, and some appear to be fundamental design issues.

As an experiment I have begun work on a pure-python wrapper that I think provides a more modern and pythonic API for NEURON. I am focusing mainly on circumventing issues that lead to difficult-to-diagnose bugs and simplifying the API wherever possible, while also keeping the core elements of the API basically intact.

There are some specific goals for the wrapper listed here: https://github.com/lcampagn/pynrn
For an example, see: https://github.com/lcampagn/pynrn/blob/ ... section.py

My questions for the forum:

1. Has someone else already begun work on something similar?
2. Is there any interest in this group for a project like this?
3. Any reasons why this is a bad idea?

There have been several moves in that direction but nothing that amounted to any start on an implementation. e.g consider
http://bitbucket.org/nrnhines/nrnpurepy which never received any changesets. It seems reasonable that a combination of ctypes and pure python would suffice for
a complete interface and the c API would be generally useful in terms of being more or less python independent. If one looks at nrn/src/nrnpython/*.cpp you will see many
functions which are a mixture of Python C API calls and calls into the rest of NEURON. I haven't looked hard enough to decide if factoring these calls is doable. One benefit certainly would be
to get rid of the large number of lines devoted to filling in PyTypeObject structures.

Thanks Michael,

I want to clarify that I am working on a wraper around the existing NEURON+Python; my suggestion to use ctypes is a separate issue.
The focus of this is to see whether I can build an API that is a bit more natural to use in python. I only intend to have partial backward compatibility with the existing API, so this provides an opportunity to rethink the way the API should work in the context of python. If this turns out to be useful, then it could become the basis for a ctypes approach later on.