While porting other Python code in the repo to run under Py3 (as well
as Py2) it was discovered there were a number of other Python scripts
which also needed porting. However these scripts are never invoked
during a build so there was no easy way to test the porting work. I
assume these scripts are for developers only and/or are
historical. Because there was no way for me to test the porting
changes on these scripts I did not want to include the changes in the
patch for the Py3 porting which fixed scripts that are invoked during
the build (the former patch is mandatory, this patch is optional at
the moment). I did verify the scripts compile cleanly under both Py2
and Py3, however it's possible I missed porting something or the error
does not show up until run-time.
Examples of the required changes are:
* Replace use of the built-in function file() with open(). file()
does not exist in Py3, open works in both Py2 and Py3. The code was
also modified to use a file context manager (e.g. with open(xxx) as
f:). This assures open files are properly closed when the code block
using the file goes out of scope. This is a standard modern Python
idiom.
* Replace all use of the print keyword with the six.print_()
function, which itself is an emulation of Py3's print function. Py3
no longer has a print keyword, only a print() function.
* The dict methods .keys(), .values(), .items() no longer return a
list in Py3, instead they return a "view" object which is an
iterator whose result is an unordered set. The most notable
consequence is you cannot index the result of these functions like
your could in Py2 (e.g. dict.keys()[0] will raise a run time
exception).
* Replace use of StringIO.StringIO and cStringIO with
six.StringIO. Py3 no longer has cStringIO and the six variant
handles the correct import.
* Py3 no longer allows the "except xxx, variable" syntax, where
variable appering after the comma is assigned the exception object,
you must use the "as" keyword to perform the variable assignment
(e.g. execpt xxx as variable)
* Python PEP 3113 removed tuple parameter unpacking. Therefore you can
no longer define a formal parameter list that contains tuple
notation representing a single parameter that is unpacked into
multiple arguments.
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
The configure script allows you to specify the python interpreter to
use via the --with-python option. There were several places where the
python interpreter was implicity invoked without using the specified
version. This can create a number of problems in an environment with
multiple python versions as is the case during the transition from
Python 2 to Python 3. Python 2 is not compatible with Python
3. Lasso's Python code is supposed to be compatible with both
versions. But during the build and when running the unit tests it is
essential the same interpreter be used consistently otherwise you can
have problems.
This patch assures whenever python is invoked it does so via the
$(PYTHON) configuration variable.
What about shebang lines (e.g #/usr/bin/python) at the top of scripts?
Python PEP 394 (https://www.python.org/dev/peps/pep-0394/) covers
this. Basically it says if a script is compatible only with Py2 the
shebang should be #/usr/bin/python2, if only compatible with Py3 the
shebang should be #/usr/bin/python3. However, if the script is
compatible with both versions it can continue to use the
compatible with both Py2 and Py3.
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
Instad of referring to an old FSF address, point the reader to the FSF
website where the latest licenses and addresses are published.
Signed-off-by: Simo Sorce <simo@redhat.com>
* tools/api.py:
use parser from the binding generator to output a list of symbols
* bindings/bindings.py;
add private flags to not clobber 'private' fields of structures or
methods not exported in bindings like _get_type.
Benjamin Dauvergne
John Dennis
Simo Sorce
Frédéric Péters
Damien Laniel