I think the python 3 should be in such a form that it’s backward compatible with 2.7 one
@MZamanMughal Could you elaborate a bit on backward compatibility? For instance, do you mean the python3 code must be able to run within python2.7 environment?
1 Like
For my 2 cents, I’m coming into HTM after having learned and have been using Deep Learning, which is predominantly being taught using python3. HTM simply needs more people coming in and experimenting with it, and trying to maintain backward compatibility (assuming that’s what @MZamanMughal is asking for) is probably mis-allocated energy.
Other advantages of focusing on Python3 exclusively is that CPython development tends to focus on version 3 of the language. I know that I’ve read that 2 is faster than 3, but I would prefer to live where there is active support, and as we’re making our way towards the release of 3.7 in a year, 3 will become faster.
(3.5 seems to be faster than 2.7 in various areas anyway…)
https://igordavydenko.com/talks/by-pycon-2017/#slide-17
At least to me, I don’t see any major advantages in fighting to maintain backwards compatibility. Full steam ahead.
I don’t either. I think you can assume someone willing to work with an HTM fork would be willing to work with Python 3.
Yes exactly, written in a way that python 2.7 can also understand the python-3 code. Quite do-able stuff.
Great points but @MaxLee to me the compatibility helps end-users in a way to reduce the time cost that they don’t waste much time in solving confrontational issues whose support for that emerging HTM ain’t available in handsome amount yet. I second your point that python new versions should be in a way that they should have to be automatically compatible to old versions and more faster then them.
I second that.
Python 2 is obsoleted, don’t waste resource supporting both.
@chhenning This applies also to your repo, why did you choose to keep both?
And another Q: Your “merged” repo (c++ + py), will it still offer running PURE python version? Meaning for the people who don’t want c++, can they ignore it and experiment just with PY? This is imho more important feature than py2.7.
1 Like
Well one (python2.7) works the other is migrating to python3.
Also, in the beginning I thought I might have to make my pybind11 modules available to python 2.7 as well.
Can you use pure python without nupic.core?
Ideally, a cmake installation would copy the binaries and python into a working setup.
Can you use pure python without nupic.core?
Yes, c++ bindings are only alternative, optimized implementation to the pure python classes.
Are you sure about that? For instance, where is the class SparseBinaryMatrix in nupic?
Wow, so something has changed a lot!
@rhyolight it’s not possible anymore to build nupic without the bindings? Would it still be easily achievable?
For example for TM you still have both versions: Py, and CppShim
I wonder if people would be interested in pure python repo for quick prototyping?
Yeah, we have talked about this here in the past. I think it would be a good thing.
1 Like
(are we python 3 yet
?)
The nupic.cpp library will handle Python3 now. But we need someone to start porting the .py code to Python3. Any volunteers?
I could do a couple hours a week porting py2 to py3. Point me in which direction.
I may be able to help however no guarantees. Thank you guys for the py3 support looking forward to it. Which ones by the way that need work?
Py3 support
We have a start on it:
https://github.com/htm-community/nupic.py/pull/7
@ctrl-z-9000-times is heading this up so contact him on that pull request and he can point you in the right direction. There is lots to do.
1 Like
We now have:
- nupic.cpp with python3 bindings
- converted the nupic.py repo to both py2/3
- now, according to our development directions Survey: Features & API-Compatibility - #22 by dmac decided from the community needs survey, we are beginning to move the py code (unit tests first) to the nupic.cpp repository, which will serve for both languages.
1 Like
Awesome. Last time I ran it with py2 there were still compat errors. I’m not sure if you guys have fixed it? Errors in using py2 iterators and StringIO to be a bit specific.
you are right. I’ve fixed the StringIO, but there are more tests waiting…let’s get that cleared.
there are about 2 issues, which propagate to many tests.
1 Like
Why are we abandoning swig? Did swig break some things for 3.x? It looks to me like swig knows at least something about python 3 - EG it can generate 3.x type annotations.