iteritems is no longer an available method for dict in Python 3. Using
dict.items() is functionally identical, although it creates some overhead
for Python 2.7 (creation of a temporary list). As this is only called
when tracing, this is not a big issue. For Python 3, there is no
overhead (dict.items() returns an iterator).
Details
- Reviewers
arojas - Group Reviewers
Frameworks - Commits
- R240:b6e4e645dac6: Bindings: Make generator forward compatible with Python 3
Run python3 sip_generator.py ...
Run python2 sip_generator.py ...
Both generate the same code
Diff Detail
- Repository
- R240 Extra CMake Modules
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
This adds a new build time dependency to all frameworks which support bindings. Any chance to simply port it to python 3 instead?
Dropping python2 means dropping support for any distro not providing python3 clang bindings. AFAICS e.g. Fedora only has python2 bindings.
I consider future a very minor addition, compared to everything else needed for generating the bindings. And there still is the option to not generate the bindings at all (which is a quite popular choice).
Another option is to include a wrapper function directly in the code, instead of importing it
Third option: just use original.items(). This is slightly more expensive in python 2 (it generates a temporary list<k,v> instead of passing an iterator), but is functionally identical. I don't think the overhead is an issue here - it is only called when tracing. For python 3, future.utils.viewitems(dict) is identical to dict.items().
Python3 still can't be used after this change: python2 is explicitely required at FindPythonModuleGeneration.cmake:177 (and all subsequent calls to sip_generator.py are done with ${GPB_PYTHON2_COMMAND}). This can be adjusted in another review though.
So, tested on Arch, openSUSE TW and Leap 15.0 ...
@arojas - can you accept, also for the two other reviews?