Happy New Years!
In the past few days I have started migrating nupic’s python code base to python 3. I started out with the “2to3” script which worked quite well. The output can be found here.
Some of the examples and tests are now running through and progress can be found here. Please note that nupic.bindings is now using the pybind11 library.
There are still many bugs and holes but the results are encouraging.
Any questions or comments are welcome!
Regards,
Christian
All the new bindings are here. There also is a visual studio solution. You can try to build the nupic_ext project which will generate the bindings.pyd file (dynamic lib). This file has to copied into your nupic source folder and voila you can import it.
Of course, you also need pybind11 but it’s header only and so, very easy to add.
Let me know if you have any issues or questions.
Very good.
This will take a few days to fold this into the CMake build and remove SWIG.
I am in the middle of adding wrappers for the C# interface (the first 4 classes). When I get those to compile I will break off and merge in your pybind11. Then I can continue with the rest of the C# interface.
We are getting closer to a community build for nupic.core.
Forgive me if this sounds stupid but I am not a Python guy. I do PERL and C (not C++) and am wondering just how big a task this porting is and what are the hard parts? Library incompatibilities? Deprecated features? Changes in the assumed environment? Changes to the language to the point where it is really a new language?
Why am I asking?
We are planning to add Raspberry PI type platforms to our product mix and adding Python as one of the house languages is under consideration. Could this have some long-term support issues highlighted by the problems you are having?
@Bitking Thanks for you interest. I think for one person the task is quite huge and I must admit that I’m still stumbling in the dark a lot of times. For instance there are these swig definitions (aka *.i files in the bindings folder) which define a lot of the interface behavior. I personally have never worked with swig and some of the stuff I don’t quite understand. My hope is that the new python bindings which are completely rewritten with modern c++ can help others. You know, it’s all about documentation and testing. 
Another issues are, Windows is not very well supported and the whole capn proto thing. I hope to change all that with my community fork.
I don’t quite get the last part of your question? Once Python 3 is a first class citizen long term support should be possible.
@David_Keeney There are some changes code changes to the non-python related parts nupic.core. Can you wait until I have add everything to my community fork? It should be done in a fews days time.
@Bitking I am just getting started with the C++/clr (managed code) for the C# interface. When I finish that I can probably give you a C only interface if you need it. Then Perl after that if there is still interest.
@chhenning Sure, take your time. I have lots to do on the C# interface. This is not hard but there is a lot of it.
Please don’t worry about me - I am doing my own thing with straight C code.
I am using some of the HTM ideas but I don’t have much interest in the nupic model.
It solves different problems than I am working on.
I was asking about the general Python environment.
I have Googled regarding the porting & compatibility issues and reached the same conclusion you mentioned: Python 3 should be OK for us to use.
I’m quite interesting in testing out NuPIC and I know that talk of migrations have been a thing for quite some time and I am quite glad that someone is undertaking it. Is there an ETA for the official release of a python 3 compatible NuPIC?
@roya004 Let’s take stock by the end of January. I’m in the process of migrating nupic to python 3. I think it’s going ok but I’ll need some help from Numenta at some point. There are a few question that I’m collecting and will post them soon.
That’s some great news!
Will it be backward compatible?
Yes, there will be two nupic versions. One for python 2.7 and one for python 3. I think this is the best way for now. Unless someones tells me it’s not.
Unless someones tells me it’s not.
2 separate versions sounds like a complete nightmare to maintain. Would not recommend. It would be best to make a version that works in python3, then also double check that it works in python2.7
Here is my reasoning. The base is nupic which is python2.7. What I’m working on is to migrate that code to python3. There are some differences in syntax and behavior between these two version. For instance:
Most of the differences can be taken care of by the python’s 2to3 tool but I find myself patching a lot of errors manually. My progress can be tracked here. Apologies for the messy markdown.
There are ways to have one codebase which supports both flavors. But I think python 2.x is on its way out and pure python3 will be better in the long run.
I hope this make sense…
Does anyone want / need python 2? In the community fork, why not just make it python 3 only?
@rhyolight Since I’m reworking the whole python interface to remove swig and all of nupic.core C python code, I think there might be some demand? At least for Windows I can see it.
But yes, for now I’m focused on python3.