Python 3 migration

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 :pleading_face:?)

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 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.

I’m looking to build the 3.x work-in-progress version, but I don’t know how to get started.

I’ve installed pybind11 2.0.1-4, and am on a Linux Mint 19.1 system.

If I run py.test from the top-level directory, I get lots of:
ModuleNotFoundError: No module named ‘nupic’

I assume this means I need to generate the pybind bindings, but how?

It appears 2 of the links in the message I’m replying to are dead now.

Thanks!

Dan, it might help you to see how I got the nupic.cpp working in python 3 here:

Python2 -> Python3 is a big change - more than Python1 -> Python2 was, and more than Python3 -> Python4 will be.

The biggest change is that strings are unicode by default instead of a bunch of octets. Also, parts of the extension module API changed.

The one people complain about the most is probably that print became a function instead of a statement.

Originally, the core team wanted us to run our code through 2to3, but a lot of people have been finding that writing code to work on both as a single codebase, works pretty well.

Hi @breznak

Are we done with nupic.py py2 to py3 migration? If not what are the remaining issues?

Cheers

Hi Jose,

The community fork of nupic fully supports both python2 as well as python3.

However the codebase as a whole is not yet stable so we are not advertising that its done.

1 Like

I’m hoping to try a nearly-1-million-line-project that currently uses Numenta nupic with nupic.cpp before long.

In what ways are nupic.cpp anticipated to be less than fully production-ready? Does it trackback? Segfault? Give wrong results?

PS: I was pleased by the unit test situation for nupic.cpp.

Worse than a segfault, we’re changing the public API. No more argument names like “n” or “w” means ppl using those keyword arguments will need to rewrite stuff. Also im making all of the algorithms use an SDR object instead of lists of floats, which is another big change for the existing users to deal with. In the near future we hope to rename / reorganize all of the modules …

1 Like