# Proposal to introduce pybind for move toward Python 3 compatibility

**URL:** <https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110>\
**Category:** NuPIC Community Fork\
**Created:** [November 28, 2017, 8:00pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110 "2017-11-28T20:00:48Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![David\_Keeney](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/david_keeney/32/1616_2.png) [@David\_Keeney](https://discourse.numenta.org/u/David_Keeney)\
**Post date:** [December 11, 2017, 8:21pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/21 "2017-12-11T20:21:30Z")

</div>

@chhenning This sounds interesting. There may be some overlap with what the three of us are doing.

What I was trying to do was get it all to build using MSVC 2017 with all of the latest dependencies which would then allow us to support Python3. It turns out that it is not that simple. I am making progress but it is slow slogging through the compile errors in the Swig generated C++ code. And I have not even gotten to the bindings yet. My thinking is that it is best to have a baseline that we know works on MSVC 2017 before we start modifying it to add the other language bindings. I don’t think I am very far away from getting this working but it is slow.

As I understand it, @heilerm is starting with the raw C++ code (without all of the Python stuff) and getting that to build. I know that the python is embedded deeply into the C++ code. I think once I have my base working I will start working with this approach and see if we can condense the nupic.core code down to just C++. I would like to get rid of most of the dependencies. It is just way to complicated.

Your approach I think is to go directly to the existing C++ code, bypassing the Swig files using pybind11. Unfortunately pybind11 can not be used to interface other languages like C# which is our objective. But it is good to know there is a way to support Python without SWIG if we decide to use something else for C#.

---

<div class="post-metadata">

**Author:** ![heilerm](https://avatars.discourse-cdn.com/v4/letter/h/9fc29f/32.png) [@heilerm](https://discourse.numenta.org/u/heilerm)\
**Post date:** [December 11, 2017, 8:35pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/22 "2017-12-11T20:35:35Z")

</div>

> [@David\_Keeney](#):
>
> As I understand it, @heilerm is starting with the raw C++ code (without all of the Python stuff) and getting that to build.

Yes, it’s just a foobar library right now. Some simple CMake and project structure stuff. I’m figuring out how best to setup swig to generate wrappers from the interface bindings. Eventually, adding all the necessary infrastructure used in nupic today. Appveyor, etc. Then, plop in the C++ source and header files, hopefully extracting all the python stuff in that process.

---

<div class="post-metadata">

**Author:** ![chhenning](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/chhenning/32/3821_2.png) [@chhenning](https://discourse.numenta.org/u/chhenning)\
**Post date:** [December 11, 2017, 9:37pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/23 "2017-12-11T21:37:47Z")

</div>

@David_Keeney @heilerm I’m trying to offer two things. One is a MSVC2017 solution to build/debug/extend nupic.core c++ code. This is pretty much accomplished in the [visual\_studio\_2017 branch](https://github.com/chhenning/nupic.core/tree/visual_studio_2017). Secondly, I’m trying to make nupic.core available to python 3 users. My work in progress in on the [pybind11 branch](https://github.com/chhenning/nupic.core/tree/pybind11). If I’m correct a lot of nupic.core c wrapper code for python can be removed.

As for the c# bindings. I have a feeling that all new fancy HTM algorithms are implemented and tested with python these days. Hence c# bindings would not have access to that easily. There is [c++ htm research repo](https://github.com/numenta/htmresearch-core) but it’s not very active as well. I might be wrong but if you like to do htm then you need to stick to python and c++.

Just my two cents.

---

<div class="post-metadata">

**Author:** ![heilerm](https://avatars.discourse-cdn.com/v4/letter/h/9fc29f/32.png) [@heilerm](https://discourse.numenta.org/u/heilerm)\
**Post date:** [December 11, 2017, 9:56pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/24 "2017-12-11T21:56:06Z")

</div>

That would conflict with the [extraction plan](https://discourse.numenta.org/t/nupic-core-extraction-plan/2115), am I wrong? It seems like the development team intended core to be wrapped in other languages using swig.

---

<div class="post-metadata">

**Author:** ![heilerm](https://avatars.discourse-cdn.com/v4/letter/h/9fc29f/32.png) [@heilerm](https://discourse.numenta.org/u/heilerm)\
**Post date:** [December 11, 2017, 9:58pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/25 "2017-12-11T21:58:02Z")

</div>

> [@Nupic.core Extraction Plan](https://discourse.numenta.org/t/nupic-core-extraction-plan/2115/1):
>
> NuPIC is currently undergoing a major refactoring, with the goal of extracting a C++ “core” that contains all CLA algorithms. This will provide a core repository so other language bindings can be created aside from Python.

Seems to be the direction, as stated here. Did that change?

---

<div class="post-metadata">

**Author:** ![rhyolight](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/rhyolight/32/3922_2.png) [@rhyolight](https://discourse.numenta.org/u/rhyolight)\
**Post date:** [December 11, 2017, 10:02pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/26 "2017-12-11T22:02:02Z")

</div>

That extraction plan is old. We mostly finished it. But we only extracted Python. C++ does contain all algorithms now.

---

<div class="post-metadata">

**Author:** ![rhyolight](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/rhyolight/32/3922_2.png) [@rhyolight](https://discourse.numenta.org/u/rhyolight)\
**Post date:** [December 11, 2017, 10:02pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/27 "2017-12-11T22:02:17Z")

</div>

> [@heilerm](#):
>
> It seems like the development team intended core to be wrapped in other languages using swig.

That is what we intended, yes.

---

<div class="post-metadata">

**Author:** ![chhenning](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/chhenning/32/3821_2.png) [@chhenning](https://discourse.numenta.org/u/chhenning)\
**Post date:** [December 11, 2017, 10:06pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/28 "2017-12-11T22:06:50Z")

</div>

This is great news! Thanks Matt!

---

<div class="post-metadata">

**Author:** ![heilerm](https://avatars.discourse-cdn.com/v4/letter/h/9fc29f/32.png) [@heilerm](https://discourse.numenta.org/u/heilerm)\
**Post date:** [December 11, 2017, 10:28pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/29 "2017-12-11T22:28:30Z")

</div>

@chhenning @David_Keeney This is what I’m thinking, as I understand it (a complete extraction to pure C++). Not sure yet if boost/ublas+mkl would be a suitable replacement for numpy, but that would remove the python dependency, I believe… if the tests were migrated as well. Would spend more time investigating that, down the line. Still not sure what pycapnp does.

Very rough diagram…

![image](https://canada1.discourse-cdn.com/flex030/uploads/numenta/original/2X/c/c14948ce4ef02c2dde8092b4b253c96a411c4668.png)

---

<div class="post-metadata">

**Author:** ![chhenning](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/chhenning/32/3821_2.png) [@chhenning](https://discourse.numenta.org/u/chhenning)\
**Post date:** [December 11, 2017, 10:33pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/30 "2017-12-11T22:33:03Z")

</div>

@heilerm pybind11 comes with [Eigen](http://eigen.tuxfamily.org/index.php?title=Main_Page) support. I think that might be good to use as well.

---

<div class="post-metadata">

**Author:** ![David\_Keeney](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/david_keeney/32/1616_2.png) [@David\_Keeney](https://discourse.numenta.org/u/David_Keeney)\
**Post date:** [December 11, 2017, 10:38pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/31 "2017-12-11T22:38:48Z")

</div>

@heilerm Yes, I think we can replace numpy. I don’t know if boost is the best approach or if I should just right the functions we need using the std:: library but either way we should be able to get pure C++.

By the way…major progress. My build finally completed…all 29 projects. The install also succeeded but I don’t know yet if I have python bindings. I started running the unit tests. It failed on something in SVM. Will have to do some debugging to see why the serialization did not work.

Anyway, I should have a baseline soon.

---

<div class="post-metadata">

**Author:** ![heilerm](https://avatars.discourse-cdn.com/v4/letter/h/9fc29f/32.png) [@heilerm](https://discourse.numenta.org/u/heilerm)\
**Post date:** [December 11, 2017, 11:46pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/32 "2017-12-11T23:46:04Z")

</div>

> [@chhenning](#):
>
> @heilerm pybind11 comes with Eigen support. I think that might be good to use as well.

I saw Eigen, too… and a few blogs that seemed to dispute its results. I’d like to benchmark it. I think a C++ solution would be best, though - no binding _in_ core, if reasonable.

> [@David\_Keeney](#):
>
> @heilerm Yes, I think we can replace numpy. I don’t know if boost is the best approach or if I should just right the functions we need using the std:: library but either way we should be able to get pure C++.

I’m assuming nupic went with numpy for the optimization on array operations, specifically for SDRs. Looks like uBLAS can be boosted and integrated with MKL. Seems like an optimal solution, and one that can be outsourced, but I’m not confident enough yet to defend that position.

---

<div class="post-metadata">

**Author:** ![heilerm](https://avatars.discourse-cdn.com/v4/letter/h/9fc29f/32.png) [@heilerm](https://discourse.numenta.org/u/heilerm)\
**Post date:** [December 11, 2017, 11:55pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/33 "2017-12-11T23:55:36Z")

</div>

> [@heilerm](#):
>
> I saw Eigen, too… and a few blogs that seemed to dispute its results. I’d like to benchmark it. I think a C++ solution would be best, though - no binding in core, if reasonable.

Err… Eigen is C++. Why would we need pybind11?

---

<div class="post-metadata">

**Author:** ![chhenning](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/chhenning/32/3821_2.png) [@chhenning](https://discourse.numenta.org/u/chhenning)\
**Post date:** [December 15, 2017, 1:44am UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/34 "2017-12-15T01:44:35Z")

</div>

You are correct it’s not really for python binding. But as far as I know it’s a very popular lib with some overlap with nupic.

And it’s nice to have python binding’s support already done.

---

<div class="post-metadata">

**Author:** ![rhyolight](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/rhyolight/32/3922_2.png) [@rhyolight](https://discourse.numenta.org/u/rhyolight)\
**Post date:** [January 16, 2018, 4:20pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/35 "2018-01-16T16:20:38Z")

</div>

Moved from #nupic:developers into #nupic:community-fork.

---

<div class="post-metadata">

**Author:** ![breznak](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/breznak/32/1935_2.png) [@breznak](https://discourse.numenta.org/u/breznak)\
**Post date:** [January 18, 2018, 9:17pm UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/36 "2018-01-18T21:17:09Z")

</div>

Love this proposal (pybind) for the c++11 and eigen,numpy support!

A few questions though:

- swig has ability to generate bindings into MANY languages, pybind is c+±python, I assume. Do we want to remove that functionality? Not that I’m saying we shouldn’t as maybe noone is actually using the swig bindings (other than py)? There’s java fork, …
- the move Py3, pybind11, … is a big change, I’d suggest to separate it: first pybind, then move along with py3?

---

<div class="post-metadata">

**Author:** ![chhenning](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/chhenning/32/3821_2.png) [@chhenning](https://discourse.numenta.org/u/chhenning)\
**Post date:** [January 19, 2018, 12:32am UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/37 "2018-01-19T00:32:57Z")

</div>

@breznak You are correct pybind is a big change and only targets python. But at least both environments python 2.x and 3.x are covered. If you are interested in what it looks like, you can find my current implementation [here](https://github.com/chhenning/nupic/tree/master/src/cpp/nupic/python). I think it’s in good state and so I have moved on to python 3 migration. That does not mean that I don’t find holes in my coverage but it’s easy to add.

What I really like is that I can define a python module with pybind in cpp. Then load it inside a cpp app along with some python code (file) and debug issues. There are many more advantages but this is the one I like most, right now.

Do you think nupic’s current usage of swig enables many languages? I only see python working.

---

<div class="post-metadata">

**Author:** ![breznak](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/breznak/32/1935_2.png) [@breznak](https://discourse.numenta.org/u/breznak)\
**Post date:** [January 19, 2018, 1:01am UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/38 "2018-01-19T01:01:16Z")

</div>

> [@chhenning](#):
>
> If you are interested in what it looks like, you can find my current implementation here.

I am! Sound great.  
As mentioned [Port to Python 3 · Issue #2 · htm-community/nupic.py · GitHub](https://github.com/htm-community/nupic.py/issues/2#issuecomment-358832131)  
I have trouble merging/reviewing your changes in the “original” codebase, as you probably started a new repo. Can we try to rebase the changes on a new repo with the project’s history?

> What I really like is that I can define a python module with pybind in cpp. Then load it inside a cpp app along with some python code (file) and debug issues.

That is a great feature! So we can now call Py from C++ (used to be only the other way). Does it mean removng the py classes needed in “nupic.bindings”?

> Do you think nupic’s current usage of swig enables many languages? I only see python working.

Touche 🙂 I don’t know…think not. Actually, I’ll be happy to see SWIG go. I’d just suggest asking here “Proposal: remove SWIG bindings for other languages”

Also, what do you think about the “separate bindings for each language”, vs “one bindings for all”?

---

<div class="post-metadata">

**Author:** ![chhenning](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/chhenning/32/3821_2.png) [@chhenning](https://discourse.numenta.org/u/chhenning)\
**Post date:** [January 19, 2018, 1:12am UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/39 "2018-01-19T01:12:46Z")

</div>

> Can we try to rebase the changes on a new repo with the project’s history?

Sorry you lost me here. My repo was initialized with the original numenta code and then I move from there. Is that not enough? Btw, nupic.core’s unit tests are running through (like 98% or so.)

nupic.core (the original) already makes use of embedded python. For instance when setting up a network with some python regions.

---

<div class="post-metadata">

**Author:** ![breznak](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/breznak/32/1935_2.png) [@breznak](https://discourse.numenta.org/u/breznak)\
**Post date:** [January 19, 2018, 1:30am UTC](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110/40 "2018-01-19T01:30:21Z")

</div>

> [@chhenning](#):
>
> Sorry you lost me here. My repo was initialized with the original numenta code and then I move from there. Is that not enough?

This one? [GitHub - chhenning/nupic: Community Fork of Numenta's Platform for Intelligent Computing (NuPIC)](https://github.com/chhenning/nupic)  
Can you please try to make a PR to [GitHub - htm-community/nupic.py: Numenta Platform for Intelligent Computing is an implementation of Hierarchical Temporal Memory (HTM), a theory of intelligence based strictly on the neuroscience of the neocortex.](https://github.com/htm-community/nupic.py) or numenta/nupic? I cannot achieve that.  
Also Github does not show your repo as “forked” from numenta. But maybe it’s only the web-UI not showing that, and you cloned nupic repo and then pushed into your clean repository?

Then I should be able to “rebase” to other forks. But for the convenience on GH I’d suggest cloning by the “fork” button there…

[Previous page](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110.md?page=1)

[Next page](https://discourse.numenta.org/t/proposal-to-introduce-pybind-for-move-toward-python-3-compatibility/3110.md?page=3)