Support for Python 3.x

[drmfinlay]

I'm not sure if this has come up in the past, but it would be great if Aenea supported using both Python 2.7.x and Python 3.x. I'm willing to put some work into this at some point as I've had some experience writing code compatible with both major Python versions.

I'm mainly thinking of the client-side code in client/aenea rather than the server code.

There are a few reasons supporting Python 3:

• dragonfly2 supports Python 3,
• the maintainers of natlink have been working towards Python 3 support,
• the end-of-life date for Python 2.7.x is coming up in January 2020.

This is not exactly an easy task. The six Python package should help with porting. It looks like jsonrpclib, one of Aenea's dependencies, doesn't work with Python 3 yet. pyparsing should work perfectly in Python 3, as should pywin32.

[calmofthestorm]

The server would be straightforward. Pity the concern is, as you note, mostly the client. I've had pretty good luck just using 2to3 and then running the tests, but we don't have a ton of tests:/ As such, bugs have to be found via manual testing in a somewhat buried environment.

I'm fine with dropping python 2 support if that makes it easier, once Natlink supports 3. We can just cut a branch with 2 support for anyone who can't upgrade Natlink (does a version of Natlink constrain a version of Dragon?)

With that said, I don't feel any particular motivation to do this, since this sort of thing is precisely why I recommend using it from a VM -- it will remain working as it always has regardless Python 2.7.x EOL. It would, of course, further fossilize and make working on it increasingly frustrating, but in a mature project that's not a huge concern for me.

I'm in favor of this but unlikely to dedicate time beyond comments/code review.

[drmfinlay]

I hadn't thought to run it using 2to3. It would be difficult to have complete test coverage for Aenea. It's good to hear that the tests we have work though :-)

Having a branch for Python 2 support sounds reasonable.

The latest version of Natlink works with DNS 10 surprisingly. I have that installed in a VM for testing. As I understand it, Natlink differentiates between old versions of Dragon (<= 11) that have different encoding requirements (ANSI vs Unicode), so they might not work when natlink starts supporting Python 3. I don't think those versions are worth worrying about though.

I agree that it isn't a high priority as most people will run the client code in a dedicated VM, probably with an old version of Windows too.

I'll see what I can come up with for the client code. I might also look into the server code at some point.

[drmfinlay]

@calmofthestorm

It really seems that there is not much interest in porting this to Python 3. (I know I don't need it.) I'd say that, unless that changes, we should just keep using Python 2.7, which is still the recommended version for Natlink anyway.

For those that do need it, at least for controlling an X11 system, I think it should be possible, with a little work, for Dragonfly's own X11 integration to run through OpenSSH X11 forwarding.

[calmofthestorm]

EDIT: The below refers to the client. I think it makes sense to convert the servers to Python 3.

I agree there is no reason to do so. Python 2 will continue to work even if it is no longer supported. Migrating makes sense for codebases that are still under active development, but I don't see the value proposition for a project like this that is more or less complete.

---

On a personal note, I am frustrated by the way that Python 2 EOL meant that programs that ran yesterday don't run today. I understand the distros' decision, given the labor to maintain parallel versions, and the actual EOL/deprecation timeline was more than generous, but losing local access to a great deal of Python I had come to depend on really shook me.

It's actually the main reason I switched to Rust for personal tools that I need to keep working indefinitely, though it has been a major upgrade in general. Nothing lasts forever, but statically linked binaries are more durable.

None of that applies to this project, of course. I was very clear from the beginning that I had encapsulated this into an internet disconnected Windows 7 VM that I planned to just keep using forever. I'm glad that I did.

I expect my keyboard to still work in 10 years too.

[jhslinkman]

I'll chime in here to say that OSX server support may be a compelling reason to port to python3. E.g., pyobjc is listed as a dependency and when trying to install pyobjc version 5.3, which is the last version to support python2, I get the same error mentioned here. You'll see that particular issue is resolved resolved in pyobjc 7.1.

I may wind up converting just the osx server to python3. If that works, I'll follow up here.

[calmofthestorm]

Agreed on the server. I updated my comment above to clarify.

[drmfinlay]

Exactly, Aenea is complete and works perfectly with Python 2.7. For what it's worth, I will be keeping 2.7 support around for Dragonfly, since it is an older project that has always worked with it.

Updating the server component sounds good to me.

---

Yes, I have been frustrated by this also. We have had new Dragonfly and Caster users badly affected by the handling of the Python 2 EOL. The Natlink maintainers shouldn't have had to update things to Python 3 for newcomers to easily use the software.

I agree with you that software and hardware should last. It seems that the EOL deadline was interpreted by many as a sort of "Let's Kill Python 2 Day", when it should have just been when the Python Foundation stopped supporting it — nothing more, nothing less.

It is good that we can still keep and run a VM with Aenea, Natlink, etc. Hopefully that doesn't change any time soon.