[chirp_devel] Future patches for python 3?
So, I've always loved chirp, and this weekend I wanted to contribute patches to make my radios more feature-rich, but when I looked at the mailing list to see what's needed, the python 3 issue seemed most dire (since I use fedora and they may drop the package over this :P).
As far as I can tell, here's the state of the code base with regards to python 3:
===== Fundamental issues ===== PyGtk (unmaintained) only supports python 2 - PyGObject looks good, easy to migrate, but only supports GTK+3.x. There might be a visual difference from GTK+2.x - There's a compatability shim, but it is far from perfect
Py2exe (unmaintained) only supports python <=3.5 - Use old python on windows, patch it, or use an alternative?
Windows XP only supports python <=3.4 (per docs) - Also only supports up to GTX+3.17 (~2015, unsupported)
===== Python 3 Syntax Issue Count ===== Ambiguous int vs. float division syntax: 599 Old exception syntax: 240 Print statements: 124 Misc iterator changes: 91 Misc dict changes: 89 Usage of builtin functions changed: 60 Other things: ???
I'm a programmer by day and I'd be more than willing to put in the effort for these issues, having done other hefty py3 migrations before.
Thing is that the changes that need to be made are neither small nor self-contained, so I'd like to at least give a heads up to the current maintainers (hi Dan!) and make sure work isn't duplicated if anyone is working on this already.
Any particular comments about things they do/don't want to see would be great too. My current plan is: 1. Work on the GObject problem first. If desired, I can keep the original PyGtk code working in parallel, but I think that will cause confusion in the long run. Be prepared for one monolithic patchset. Still python 2 code. 2. Work out any hidden issues that GObject has, ensure packaging works, etc. I hope there will be nothing here that isn't caught by review but experience has taught me otherwise... 3. Add disabled-by-default python 3 testing. 4. Fix things until tests work under python 3 5. Enable testing on python 3 by default (in addition to testing on python 2) 6. Test python 3 builds on my radios and share it with tech-literate hams I know to find any bugs not caught in tests 7. Eventually, python 2 will be dead and gone, and this can become the default.
Feedback welcome! I've been lurking on IRC if anyone wants to discuss as well.
Jake Merdich W7MEH
===== Fundamental issues ===== PyGtk (unmaintained) only supports python 2
- PyGObject looks good, easy to migrate, but only supports GTK+3.x.
There might be a visual difference from GTK+2.x
- There's a compatability shim, but it is far from perfect
Py2exe (unmaintained) only supports python <=3.5
- Use old python on windows, patch it, or use an alternative?
We have to have a path forward here, and running python2 only on windows doesn't seem great. If pygobject works with gtk3 on py2 and py3 equally well, then it's a start I guess, but it gets us more fractured than we are today, even with distros threatening to drop py2. There are easy ways to install/package things on linux to maintain a py2 environment on those distros, but having users running with bleeding edge py3 on other platforms and py2 on windows seems like it's going to be a larger gap to me.
Thing is that the changes that need to be made are neither small nor self-contained, so I'd like to at least give a heads up to the current maintainers (hi Dan!) and make sure work isn't duplicated if anyone is working on this already.
Several people have stated they were going to do this, but nobody has circled back with something to look at thus far. I don't have the time (or desire) to work on the conversion, but I don't want to stop anyone else from doing it. I _do_ worry a lot about creating instability for very little gain (IMHO) given we're mostly in "add new drivers" mode these days.
If we could maintain an hg branch that gets rebased often, with stable builds from default and testing builds from the py3 branch, that seems like it would be better until confidence rises. I'll happily do the work to make both builds and help with messaging to users to try to get people to help test.
Any particular comments about things they do/don't want to see would be great too. My current plan is:
- Work on the GObject problem first. If desired, I can keep the
original PyGtk code working in parallel, but I think that will cause confusion in the long run. Be prepared for one monolithic patchset. Still python 2 code.
We're going to need some serious review and testing of something like that, and I imagine it's going to be pretty gnarly as a single monolithic blob. Just fair warning :)
- Work out any hidden issues that GObject has, ensure packaging
works, etc. I hope there will be nothing here that isn't caught by review but experience has taught me otherwise...
I feel like the potential for gremlins will be high, so I'd definitely like to be able to build from another branch and encourage users to help chase out the bugs.
- Add disabled-by-default python 3 testing.
- Fix things until tests work under python 3
- Enable testing on python 3 by default (in addition to testing on python 2)
Running both when I generate a build is easy, so no worries there.
--Dan
On 11/26/2018 4:55 PM, Dan Smith via chirp_devel wrote:
===== Fundamental issues ===== PyGtk (unmaintained) only supports python 2 - PyGObject looks good, easy to migrate, but only supports GTK+3.x. There might be a visual difference from GTK+2.x - There's a compatability shim, but it is far from perfect
Py2exe (unmaintained) only supports python <=3.5 - Use old python on windows, patch it, or use an alternative?
We have to have a path forward here, and running python2 only on windows doesn't seem great. If pygobject works with gtk3 on py2 and py3 equally well, then it's a start I guess, but it gets us more fractured than we are today, even with distros threatening to drop py2. There are easy ways to install/package things on linux to maintain a py2 environment on those distros, but having users running with bleeding edge py3 on other platforms and py2 on windows seems like it's going to be a larger gap to me.
No kidding. I'm all for a homogeneous system at all times (except for very clearly 'experimental' branches and maybe an XP-only build). Stability and maintainability should be king.
My opinion is that Python 2 should remain the default on all platforms, with Python 3 being separate and experimental until we're completely certain it is stable, and then it should be a clean switch with a major release. It does look like Fedora will support Python 2 applications for at least a few more years (they wanted to remove unused py2 libraries).
Also, py2exe does seem to have some good replacements, but that's a topic for another day. Python 3.5 is still under support.
Thing is that the changes that need to be made are neither small nor self-contained, so I'd like to at least give a heads up to the current maintainers (hi Dan!) and make sure work isn't duplicated if anyone is working on this already.
Several people have stated they were going to do this, but nobody has circled back with something to look at thus far. I don't have the time (or desire) to work on the conversion, but I don't want to stop anyone else from doing it. I _do_ worry a lot about creating instability for very little gain (IMHO) given we're mostly in "add new drivers" mode these days.
If we could maintain an hg branch that gets rebased often, with stable builds from default and testing builds from the py3 branch, that seems like it would be better until confidence rises. I'll happily do the work to make both builds and help with messaging to users to try to get people to help test.
I understand the problem of flaky new contributors, but I hope I break the trend and get this done, and I'm very committed to not shipping broken code.
FWIW, I do have the pygobject code about 80% done, with mostly corner cases and packaging left. All basic functionality works, but I'll still be testing until I have personally tested every line of code in the UI folder (~69% now) and find no difference in functionality. There should be a patch coming and builds for people to break some time this week.
I'd be completely on board with keeping this in a branch until it's proven stable.
Any particular comments about things they do/don't want to see would be great too. My current plan is: 1. Work on the GObject problem first. If desired, I can keep the original PyGtk code working in parallel, but I think that will cause confusion in the long run. Be prepared for one monolithic patchset. Still python 2 code.
We're going to need some serious review and testing of something like that, and I imagine it's going to be pretty gnarly as a single monolithic blob. Just fair warning :)
Bring the pain!
The diff will be mostly line-for-line identical in its logic, but gtk2->gtk3 has renamed a LOT of things.
- Work out any hidden issues that GObject has, ensure packaging
works, etc. I hope there will be nothing here that isn't caught by review but experience has taught me otherwise...
I feel like the potential for gremlins will be high, so I'd definitely like to be able to build from another branch and encourage users to help chase out the bugs.
Again, agreed.
- Add disabled-by-default python 3 testing. 4. Fix things until
tests work under python 3 5. Enable testing on python 3 by default (in addition to testing on python 2)
Running both when I generate a build is easy, so no worries there.
:)
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
Thanks for looking into this, and here's to 2020-proofing the code!
Jake
participants (2)
-
Dan Smith -
Jake Merdich