Purpose: Make antlr code Python3-ready while keeping Python2 support
Changes:
- Generated Python3 CongressParser.py and CongressLexer.py placed in
subpackage congress/datalog/Python3/ (using antlr 3.5.2)
- Moved original CongressParser.py and CongressLexer.py into new
subpackage congress/datalog/Python2/
- Changed import section in congress/datalog/compiler.py to import
the appropriate subpackage based on python version used
- Removed original symlink antlr3 to the antlr3-python2 runtime
- Changed setup.py to create the appropriate antlr3 symlink based on
python version
- Changed the error reporting interface of antlr3-python3 runtime to
be compatible with what existing Congress code expects
(thirdparty/antlr3-antlr-3.5/runtime/Python3/antlr3/recognizers.py)
Result: tox -e py34 no longer reports any errors traced to antlr code.
Notes:
- Supporting both Python versions was not straightforward because
neither the antlr runtime nor the antlr generated code is
cross-version compatible.
- Making symlinks via setup.py is not ideal, but the best solution
I came up with among several I considered. If you have better ideas
please suggest.
- Making our own custom changes to antlr3-python3 runtime is not
ideal, but it was necessary because for some reason the
antlr3-python3 runtime broke error reporting interface compatibility
with antlr3-python2 runtime, leading to test failures in
test_compile.py and test_congress.py.
In theory, supporting our custom changes in antlr3 runtime bad, but
because antlr3 is not supported anyway, the situation is really no
worse than before. In addition, the changes are fairly minor.
- antlr4 was not adopted because it does not have support for
abstract syntax trees.
Partially implements blueprint: support-python3
Change-Id: I376aee803c4dc9953c1b5ba9311cf9c4a42f3319
0576d774a4