No attempt yet to do anything other than compile.

Codecov Report

Merging #468 into master will increase coverage by <.01%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master     #468      +/-   ##
==========================================
+ Coverage   43.06%   43.06%   +<.01%     
==========================================
  Files         299      299              
  Lines       98215    98215              
==========================================
+ Hits        42294    42295       +1     
+ Misses      55921    55920       -1

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update de19e6e...7628a67. Read the comment docs.

Thank you!!!
Should we try to compile against Python 3 within CI scripts (.travis.yml)?
There are also pytest tests executed to test the Python module - also worth updating (also in .travis.yml).
Question is if to keep Python 2 support at all (if yes, we'd probably need to create a few new build setups for CI)?
Again, thank you!

Yes, we should definitely compile and test against python 3. Python 2 is going to be around for at least as long as RHEL 7 is, so I'd like to keep support for both for the moment. Though I think that the default should move to python 3.

For the Debian package, I played around with this and found two more places to change. For simplicity, I just added them to @opoplawski's branch -- feel free to edit or remove them if required.
With these patches, I could do the (patched) tests; so calling GDL from Python 3 basically works. For Python 2 legacy, the additional option ENABLE_PYTHON2 must be given to cmake.

If there are no objections, I intend to upload a new GDL version with these patches to Debian, so that the version that will come with Buster already is a Python 3 module. I am a bit in hurry with that, since we will have a freeze soon, and this change needs review by our ftp-masters (which also takes time).

I will upload the patches for the tests ASAP.

I just uploaded the updated tests that work for Python 3. I'll take the opportunity to document here what does not work yet. I use the following GDL function for tests:

function ARG_PASS_RETURN, arg
  return, arg
end

• Complex values will abort Python

  >>> import GDL
  >>> arg = complex(1, 1)
  >>> retval = GDL.function('arg_pass_return', arg)
  % Compiled module: ARG_PASS_RETURN.
  Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"...
  Abgebrochen
  

• In Python 3, integers are long but in GDL they are int. So, the leading bits are ignored:

  >>> import GDL
  >>> arg = 2**45-1
  >>> retval = GDL.function('arg_pass_return', arg)
  % Compiled module: ARG_PASS_RETURN.
  >>> print(retval)
  -1
  

• Some array types are unknown

  >>> import GDL
  >>> import numpy
  >>> arg = numpy.arange(0, 259, dtype=int)
  >>> retval = GDL.function('arg_pass_return', arg)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  GDL.error: Calling ARG_PASS_RETURN: FromPython: Unknown array type.
  >>> arg = numpy.arange(-255, 255, dtype=numpy.int8)
  >>> retval = GDL.function('arg_pass_return', arg)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  GDL.error: Calling ARG_PASS_RETURN: FromPython: Unknown array type.
  

• Python lists, maps, and tuples are not properly handled

  >>> import GDL
  >>> arg = [1, 2, 3, 4, 5]
  >>> retval = GDL.function('arg_pass_return', arg)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  GDL.error: Calling ARG_PASS_RETURN: Cannot convert python scalar.
  >>> arg = {'1': 2}
  >>> retval = GDL.function('arg_pass_return', arg)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  GDL.error: Calling ARG_PASS_RETURN: Cannot convert python scalar.
  >>> arg = (1, 2, 3, 4, 5)
  >>> retval = GDL.function('arg_pass_return', arg)
  >>> print(retval)
  1
  

• Invalid code does not raise a GDL.error. Suppose following GDL code:

  PRO invalid_code
     this_is_invalid
  end
  

  In Python, an error message is printed, but no error is thrown:

  >>> import GDL
  >>> GDL.pro('invalid_code')
  % Compiled module: INVALID_CODE.
  % INVALID_CODE: Parser syntax error: unexpected token: 
  

…and I just rebased to the current master so that it could be cleanly merged. In that case,I would open the problems shown above as issues so that they don't get lost.

The tests fail on travis with:

-- Found PythonInterp: /usr/local/bin/python3 (found suitable version "3.7.4", minimum required is "3") 

-- Could NOT find PythonLibs: Found unsuitable version "2.7.16", but required is at least "3" (found /usr/local/Cellar/python@2/2.7.16_1/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib)

-- PYTHON_EXECUTABLE: /usr/local/bin/python3

-- PYTHON_VERSION: 3.7.4

-- PYTHON_LIBRARIES: /usr/local/Cellar/python@2/2.7.16_1/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib

-- PYTHONLIBS_VERSION: 2.7.16

CMake Error at CMakeLists.txt:878 (message):

  Version mismatch between python interpreter and libraries

-- Configuring incomplete, errors occurred!

+1 for opening separate tickets for each issue.

Thanks!

The problem is IMO here that Python 3 is not (completely) installed and the Python 2.7 lib is enforced in .travis.yml. I pushed an update for the Linux targets there; for macos I would however ask someone else since I have no experience with it.

+1 for opening separate tickets for each issue.

Done: #638, #639, #640, #641, #41

+1 for opening separate tickets for each issue.

Done: #638, #639, #640, #641, #41

Thank you!

The problem is IMO here that Python 3 is not (completely) installed and the Python 2.7 lib is enforced in .travis.yml. I pushed an update for the Linux targets there; for macos I would however ask someone else since I have no experience with it.

Will look at it

@olebole I was proposed to solve a conflict. Rebasing was not an option.

@slayoo I've successfully tested this patch on my branch https://github.com/GillesDuvert/gdl/tree/test-new-python, which is in sync with current GDL master.
It works with Python2 using -DPYTHON_MODULE=ON -DPYTHONVERSION=2 and also with python3, except that for python3 one needs to give almost everything by hand:
-DPYTHON_MODULE=ON -DPYTHONVERSION=3.7 -DPYTHON_INCLUDE_DIRS="/usr/include/python3.7m" -DPYTHONDIR="/usr/bin"
I do not know if this is a problem. If not this PR can be merged, however there is this conflict above to resolve.