Python 3 transition (was: Ubuntu 16.04 python troubles) #7717

Ubuntu 16.04 (available as beta) doesn't install python 2 by default anymore. This breaksmake check by default.

But this is not the only problem - it is possible to install python 2.7 using apt-get install python2.7 but this will only give you a /usr/bin/python2.7, no /usr/bin/python nor /usr/bin/python2...

This is really annoying as this effectively makes it impossible to refer to it as interpreter at the top of scripts, as we wouldn't want to force #!/usr/bin/python2.7 at the top of scripts, when other 2.x versions would do as well.

Maybe the time is near to port our Python scripts to Python 3.

In #7723 I made the build system invoked scripts compatible with both Python2 and Python3.

For the build system I think it's good to have both Python2 and Python3 compatibility (annoying to have specific dependencies there). This is not necessary for the other python scripts, such as the RPC tests. For practical reasons it's ok to have an explicit Python 2.7 dependency for those - though we'll have to document that in the invocation instructions.

Porting the non-build-system Python scripts in one go to Python3, without intermediate Python 2 and 3 compatibility phase is a better use of our time. We'll have to decide when, though. Like the c++11 change, it's probably something some people feel very strongly about.

Hi. I didn't know about this and decided to download Beta 1. AFAIK, Ubuntu still defaults to Python 2.7.11. That's what python-version returns, and Armory runs & compiles just fine. (Armory is still Py2-only.) I did this without apt-getting python2.7. Am I missing something? I see that Beta 2 should be out tomorrow. Maybe there will be a switch at that time? Doesn't seem wise to switch once in beta mode, though.

Thanks.

I installed the most minimal image (the cloud image) of the 2016-03-18 daily. This comes with Python3, not Python2. There has also been a lot of public attention about this.

It's very possible that you got 2.x as a dependency of something. python --version will never return a 3.x version. Python 3 is always called python3, so you should do python3 --version.

To be clear, there is no "switch": Python3 is installed by default. Python2 is installed optionally. These have co-existed for quite a while, and can still happily coexist, but a lot of people think Python2's EOL is starting to approach. Distributions dropping Python 2 from the default (minimal) install is a clear omen to that.

@laanwj - Thanks for clarifying. Just to clarify things on my end, I installed the desktop ISO and let VMware auto-install everything. I'm guessing something in the desktop version requires Python 2, as I didn't manually install it.

In any event, I'm glad to hear that work is progressing on upgrading the tests to Python 3. Having compatibility for both is good but, as mentioned in the meeting yesterday, maintaining compatibility is extra work. As long as there's no supported environment that's Py2-only, I say take the path of least resistance. Just keep in mind that the 2-to-3 script out there (or at least the one we used to create a Py3 Armory prototype) is a bit buggy. Hopefully manual intervention will be kept to a minimum.

Just to clarify things on my end, I installed the desktop ISO and let VMware auto-install everything.

Can confirm this, the desktop image sure comes with a lot of kitchen sinks. Looks like some component (rhythmbox?) still pulls in python2. Of course, we can be pretty sure that's a temporary condition, and the next release (or even an update of this one) will probably migrate those too.

Just keep in mind that the 2-to-3 script out there (or at least the one we used to create a Py3 Armory prototype) is a bit buggy

I've noticed too, it's a nice help but one certainly shouldn't trust its output verbatim, but review the patch like any other.

Indeed, the script also won't really help you to unfiddle the py2-str mess to get "proper" bytes or strings

I think the script also chokes on some function calls that act as macros. Not all, but some. (It really hated a pervasive one in particular in our code. We never quite figured out what was happening.) I don't think that'll be a major problem here but it is something to keep in mind if the script is used and errors pop up.

Anything left to do here?

No I don't think so.