Python 3 migration

python

#21

I think the python 3 should be in such a form that it’s backward compatible with 2.7 one


#22

@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?


#23

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.


#24

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.


#25

Yes exactly, written in a way that python 2.7 can also understand the python-3 code. Quite do-able stuff.


#26

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.


#27

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.


#28

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.


#29

Can you use pure python without nupic.core?

Yes, c++ bindings are only alternative, optimized implementation to the pure python classes.


#30

Are you sure about that? For instance, where is the class SparseBinaryMatrix in nupic?


#31

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?


#32

Yeah, we have talked about this here in the past. I think it would be a good thing.