Martin Cooper via chirp_devel wrote:
I think one of the main sticking points to a complete Python 3 version of Chirp is the GUI. With the py3 branch, Chirp is moving to wxPython (wxWidgets), and really, nobody has stepped up to do significant work on that. A start has been made for clone-mode radios, but when I looked into it with a live-mode radio some time ago, it seemed to me that there were design ideas in place, but not enough hints to pick those up and run with them - at least not for someone largely unfamiliar with wxPython, like me. There also seemed to be some other design changes to the way the GUI works that are probably not directly related to wxPython.
I still run a revision of the py3 mercurial branch from February 2020 with only some minor syntax changes with the GTK-based GUI. PyGObject3 has a compatibility mode with pygtk2 so most functionality still works without modification.
The bigger issues I would say are more procedural than purely technical. Unfortunately, the patch guidelines, if strictly enforced without exception, are not conducive to allowing large-scale compatibility fixes with Python 3 in one or a few commits, if we are to have working builds for both major Python versions every commit. That is not to mention intervening driver updates and additions, which seem like a higher priority.
Additionally, the Python packaging world has a new paradigm called PEP-517. Most notably, setup.py is deprecated, pyproject.toml takes its place and setuptools's role becomes one of many build tools to choose from rather than the end-all of Python packaging.
A decent amount of the py3 codebase does work, though. For example, I got to the point where I can use chirpc (the CLI version) to read and write memories with my live-mode radio. So the core functionality is there, for at least some drivers. (I know a few other folks have worked on drivers for their specific radios too.)
Confirmed, at least for baofeng_common.