I was not yet part of the mailing list when the above was posted, but for what it’s worth, I’m not sure supporting both simultaneously will be worth the effort. In my experience, it’s almost always a non-trivial amount of overhead. That may make more sense if Chirp was a library with widespread downstream dependencies. Being an app, it may only make sense if it’s part of the validation strategy (i.e., test compatible long enough to gain confidence in correctness before dropping the requirement that code must run in Python 2).

Yeah, I hear you, but the things that have to change for me to be confident in py3 are extremely non-trivial. 95% of the people using chirp are doing so via the Windows installer, and that means 95% of the people running chirp are doing so on py2. When I feel like running on py3 is as reliable as py2, or that the cost/benefit has changed I'll switch that build and we can start dropping py2 stuff. The bits I'm adding are certainly intended to be rip-out-able when needed.

I've spent the better part of the last decade working on a project much (much) larger than chirp that still supports both. Not as much math and manipulation of actual bytes(), so less to trip over, but...

--Dan