REP-0003: explain Python 3 plans for Hydro

[jack-oquin]

No description provided.

[dirk-thomas]

I would not recommend to users to change their default Python interpreter to Python 2. This could have some very ugly side effects with other libraries installed which do not work with Python 2 anymore.

[jack-oquin]

My understanding is that Ubuntu will provide bilingual support, just as we will.

If they do not, we will need to recommend that users not run Raring on any operational ROS systems.

[jbohren]

Is it possible to make rosrun / roslaunch automatically use python 2 when launching python scripts? Or even make this switchable via ROS environment variable?

[jack-oquin]

I doubt it, Jonathan.

Individual executable scripts could specify python2 in their shebang ("#!") line, but that does no good for modules invoked by other scripts.

[jbohren]

@jack-oquin couldn't rosrun/roslaunch run the script with a modified PYTHONPATH and use python2.7 /path/to/script.py which would bypass the shebang?

[jack-oquin]

Interesting idea, but beyond my Python expertise. Modifying the script on the fly has authorization issues, I suspect. Would the roslaunch script, itself, be running in python3?

Would you be willing to try it as an experiment?

[jbohren]

Well, you don't actually have to modify the script. If you set the
environment variable PHYTHONPATH, then you can make sure only python 2.7
modules will be prioritized, and then instead of just using the shell to
read the shebang to figure out how to execute the scripts you can execute
the script with python2.7 explicitly.

[jack-oquin]

While Jonathan's ideas are definitely worth investigating, we lack time in the Hydro release schedule to pursue them far enough to bet the plan on that working. Perhaps we can use his approach in I-turtle, with packages marked to indicate which Python version(s) they support.

As soon as Raring builds are available, we can definitely test whether a ROS system will run with python2.7 as the system default. That will reveal whether or not Dirk's concern is a show-stopper.

Meanwhile, we should merge this REP-0003 update, because it describes reality more closely than the previous text.

Votes?

[dirk-thomas]

-1 for the change recommending users to change their default Python interpreter to 2.7.
+1 on all the other improvements to the text.

[jack-oquin]

Another high priority for conversion is rosunit:

$ python3 tests/test_unique_id.py
Traceback (most recent call last):
  File "tests/test_unique_id.py", line 122, in <module>
    import rosunit
  File "/opt/ros/hydro/lib/python2.7/dist-packages/rosunit/__init__.py", line 43, in <module>
    from .core import xml_results_file, rostest_name_from_path, create_xml_runner, XML_OUTPUT_FLAG
  File "/opt/ros/hydro/lib/python2.7/dist-packages/rosunit/core.py", line 48
    print "[ROSUNIT]"+msg
                    ^
SyntaxError: invalid syntax

This one looks easy to fix.

[jack-oquin]

I discovered that the bilingual scripts also need to work on Precise and Quantal. They provide Python 3.2 in addition to the default interpreter, 2.7.

Otherwise, it would be absurdly difficult for developers to make and test those changes. They need to make sure every script works on both Python versions.

[jack-oquin]

Please review the revised plan: vote and provide feedback. We need to publish something soon for Hydro. The version it replaces is totally wrong.

There remains much effort for ROS to handle Ubuntu 14.04 well in J-turtle. Indigo will need to provide a good script migration environment for that to happen.

To provide focus, I would like to create an Indigo planning SIG for Python in general and Python 3 migration in particular. I can help organize it, but will need participation from the rest of you, who all have better Python skills than me.

[tfoote]

I thought we had to do >=3.3 to get full compatability with 2.7.

Otherwise it looks good.

[jack-oquin]

I am hardly an expert, but my on-line reading suggests that while 2.7+3.3 is cleaner (fewer hacks), 2.7+3.2 should be OK.

The main advantage of 3.3 over 3.2 is that it accepts the u'xxx' string literal notation. That eliminates one annoying migration effort. The 3.2 alternative is eliminating the u'xxx' prefixes and specifying from future import unicode_literals, which is not as nice but does work.

Why support 3.2 at all? Because Precise LTS will still be supported in Indigo, and we need to release the core python3 compatibility then for developers to use as a base for porting robotics packages in advance of Ubuntu 14.04 and J-turtle, when everything would otherwise stop working.

[tfoote]

Good point on the Precise LTS. I think we're ready to go with this update.