python3

[jreiser]

python2.7 will not be supported in a couple years. What are the plans for aa_macro to move to python3?

[fyngyrz]

Well, as it stands, I have no such plans at present; Python 3 offers me nothing (well, it offers me a heck of a lot of work I wouldn't otherwise have to do), so I have no interest in it at all for existing projects.

Also, Python 2 won't go away, and it doesn't appear to be broken in any way that matters to the aa_macro project, so support of it from the author(s) isn't really meaningful in terms of its future usability. Even so, I suspect someone will pick up that load, as Python 3 isn't really Python, it's a different language: Python 3 won't run Python code, and Python 2 won't run Python 3 code. It was a grievous mistake to eschew backwards compatibility in Python 3, IMHO. It created a fracture that will never heal. And Python 2 is a great language.

As far as the unknown future goes, two things.

First, I may change my mind. I can be like that. :)

Second, I may expire. I'm not a young man, and my health is poor. In which case perhaps someone else will pick up the torch.

Having said all that, I'm completely open to someone else moving the project to Python 3. There's an extensive test suite provided in the repo, and if/when the purported port can pass that suite, then a Python 3 version is good to go. Moving the test engine to Python 3 would be a doddle. There's very little to it, other than comparing existing, canned output with what the test drive of aa_macro generates.

[jreiser]

A significant and influential subset of users work in environments where each software tool must have a maintainer. Some person, group or organization must be identified in advance as being responsible for the tool and available to fix bugs, particularly security bugs such as insecure use of temporary files or symbolic links in the file system, etc. "leaf" tools such as aa_macro might be self-maintained by the user, but things like python probably cannot be. Also, if a maintainer announces "End Of Life" for some software, then the users must find another maintainer or implement a plan to discontinue its use within one year. Those users often find it difficult to consider using a tool such as aa_macro that depends on python2.7 when maintenance of python2.7 is an open question.

It would help if aa_macro had an explicit list of known incompatibilities with python3, together with comments about the scope, impact, and suggested avenues for resolution.

[fyngyrz]

Appreciate the comment.

Critically, aa_macro's future WRT Python 3 is not set at this time. I don't see it as an issue of much (any, really) significance. The project can be forked or enhanced by anyone; that's what GitHub is all about, and to say my attitude about it is permissive is to radically understate the case.

If someone thinks this matters (pretty sure it doesn't matter at all, but) they are 100% free, and encouraged, to pursue the task. The supplied test suite and aa_macro's high internal modularity should make it about as easy as possible.

Should that come to pass, I'll be happy to maintain both as long as I'm around, as incremental changes are not a significant workload.

Doing a full-bore rewrite for no results-oriented reason of my own, however, strikes me as spending a large amount of my time very poorly indeed.

Of course, someone may convince me otherwise. I'm not seeing it at present, but that's the thing about the present, isn't it?

[Quantum-Electrodynamics]

I found out that python comes with a script that can make python2 code into python3 code. It is able to run after the transformation.

[fyngyrz]

Quantum-Electrodynamics, have you run the test suite provided in the repo? Did it work?