[Feature Request/Maintenance]: Resolving Python2 vs. Python 3 incompatibilities

[bdorney]

Brief summary of issue

Discussing differences between python2 and python3 in light of future upgrade to CERN CentOs 8 cc8 where python is python3 by default.

This list below of issues is not exhaustive and before work begins I would encourage other developers to comment about additional incompatibilities (including differences in libraries/dependent packages).

This might even warrant multiple staged PR's to address specific subsections of this issue.

Types of issue

• [ ] Bug report (report an issue with the code)
• [x] Feature request (request for change which adds functionality)
• [x] Maintenance

Expected Behavior

Should resolve python incompatibilities.

Check Dependent Packages Have python3 Equivalents & No Breaking Changes

This may be a harder fix then what is described below; Presently the following packages are needed for gem-plotting-tools:

• cx_Oracle
• pandas
• root_numpy
• sqlalchemy
• numpy
• tabulate
• pytz
• python-dateutils
• six

Even if python3 compatible packages exist above there could have been breaking changes in the API for the above packages when moving from python2 to python3. Probably the easiest to check is testing (either in a docker_CI case or by a developer).

Additionally in the event that python3 compatible packages do not exist development will be needed to ensure functionality remains the same and that the change is transparent to the end user.

Update syntax of print statements

All print statements should have syntax updated to reflect a function call, e.g. print( stuff ) vs. print stuff.

Files need to change:

• anaSBitMonitor.py
• anaSBitReadout.py
• anaXDAQLatency.py
• packageFiles4Docker.py
• fitting/fitScanData.py
• macros/gemPlotter.py
• macros/gemSCurveAnaToolkit.py
• macros/gemTreeDrawWrapper.py
• macros/plot_eff.py
• macros/plotSbitThreshComp.py
• macros/plotSCurveFitResults.py
• macros/plotTimeSeries.py
• utils/anautilities.py
• utils/scurveAlgos.py
• utils/threshAlgos.py

Change exit to sys.exit

All statements of the form:

exit(args)

Should change to:

import sys
sys.exit(args)

With import statement present if appropriate.

Files needed to change:

• macros/calibrateThrDac.py
• macros/clusterAnaScurve.py
• macros/gemPlotter.py
• macros/gemSCurveAnaToolkit.py
• macros/gemTreeDrawWrapper.py
• macros/plot_eff.py
• macros/plotSbitThreshComp.py
• macros/plotSCurveFitResults.py
• macros/plotTimeSeriesHV.py
• macros/scurvePlottingUtitilities.py
• macros/timeHistoryAnalyzer.py
• utils/anautilities.py
• ana_scans.py
• anaUltra*.py
• anaXDAQLatency.py
• packageFiles4Docker.py

Integer vs. Float Division

Probably a thorough check of mathematical operations need to be checked to ensure that integer division is preserved when/if requested.

E.g. in python3

5 // 2 = 2
5 / 2 = 2.5

Harder to find files affected; this is left as an exercise to the developer to find...

Current Behavior

Many instances of python3 incompatible code.

Context (for feature requests)

When moving to cc8 the default version of python will be python3.

[lmoureaux]

Probably the easiest way to get started is to run 2to3. It will update all print statements and many other things, see the docs for details.

[bdorney]

Probably the easiest way to get started is to run 2to3. It will update all print statements and many other things, see the docs for details.

What a great comment! Thanks for this link!

[lpetre-ulb]

As a follow-up I would like to ask what is envisioned for Python 2?

Indeed Python 2 is deprecated since a far too long time and CC7 already provides Python 3.4. Python 2 will not be supported at the end of the year and I think we will not use SLC6 anymore so I would be in favor not to support Python 2 once this issue is fixed. Moreover some functionalities are slightly different between Python 2 and 3 and it is not always easy to properly support both.

In any case 2to3 is a good starting point as Louis said. Obviously careful tests will have to be perform in order to avoid any regressions because everything cannot be automatically converted (e.g. some exception methods).

[jsturdy]

As long as there are machines that will use cc7 that we might conceivably target supporting, we will plan to ensure python2.7 "compatibility". Yes, python2.7 will be "unsupported" starting next year, but it won't magically disappear overnight (and it will still be possible to install on centos 8. There may also be some gotchas to look out for regarding interpreter name, but won't worry about this until we have a beta centos 8 image to play with (hopefully around early fall)

[lpetre-ulb]

Legacy will never be ported to Python 3 and will keep being based on Python for the time being.