“Annotation” feature drops compatibility with Python 3.6

[latk]

Recently, the following line was added to autoprogram.py:

from __future__ import annotations

However, the annotations feature was only added in Python 3.7 per PEP 563. This breaks autoprogram on Python 3.6, which still has upstream support until the end of the year.

We encountered this problem on our CI builds for the gcovr project, which we run on 3.6 to ensure compatibility. I note that autoprogram uses 3.7 as the oldest version.

What is the intention here?

• Does autoprogram intend to support all Python versions with upstream support? If so, how can the annotations feature be made unnecessary? The annotations feature is not necessary for type annotations, but merely changes the evaluation order in order to directly support forward references.
• Or will autoprogram as a developer-focused tool only target more recent Python versions, and explicitly drop support for 3.6? If so, please mention this in the changelog.

In any case, it may be time to update the classifiers in setup.py – they claim support for Python 3.3 and Stackless Python, both of which seem like untested claims :)

[elyezer]

An alternative would be to require https://pypi.org/project/future-annotations/ for Python 3.6

[elyezer]

Not sure if we can get this to work on Python 3.6+ https://github.com/sphinx-contrib/autoprogram/pull/43/files#r574630429

With the current annotations usage it seems not to be possible to work with python 3.6

[kousu]

3.6 is EOL at the end of the year so maybe it's fair to just move on? I've given #48 to do that.

[langston-barrett]

Thanks for the issue @latk, I've made #51 to focus on the more general part of your question around "intention".

My current leaning is that it's not super important for this tool to support every Python version - it doesn't need to match the Python version that a given project actually runs on. That said, I'm very open to feedback on this and not committed to that conclusion.

[latk]

Thanks, that is great to hear!

it doesn't need to match the Python version that a given project actually runs on.

Yes it does, within reason. Whatever Python version is used, it must be able to run both Autoprogram and the target program, since Autoprogram must execute the target program to get at the ArgumentParser object.

In practice this is not a big deal because Python has decent backwards compatibility, but the PEP-387 backwards compatibility policy allows breaking changes after two versions with deprecation warnings. This means code could run without warnings in 3.6, warn in 3.7 and 3.8, and stop working in 3.9. (Of course in practice, the issue with upgrading a project to a newer Python isn't the language but availability of wheels for dependencies). Importing from __future__ is a useful tool to manage transitions between versions, but also sets a hard lower limit on the supported version.

In light of this, I would humbly suggest that Autoprogram adopt a policy such as:

• the next-oldest Python release if broad compatibility is required (e.g. minimum 3.7 while 3.6 still has upstream support)
• the next-newest Python release if cutting edge is desired (e.g. 3.8 while 3.9 is the newest release)
• all Python versions with upstream support (e.g. 3.6)
• a Python version supported by ReadTheDocs stable (e.g. 3.7)
• whatever Python is the default on major Linux distros (e.g. currently 3.7 for Debian stable). But admittedly, there can be too much concern for that. I've lost too much hair over trying to support whatever outdated versions RHEL/CentOS is shipping. Containers are a thing.

[langston-barrett]

it doesn't need to match the Python version that a given project actually runs on.

Yes it does, within reason. Whatever Python version is used, it must be able to run both Autoprogram and the target program, since Autoprogram must execute the target program to get at the ArgumentParser object.

Right, I was being a bit short here but my understanding matches yours - it's probably okay if Autoprogram requires a newer version of Python, so long as that version is backwards compatible (i.e., within two versions).

In light of this, I would humbly suggest that Autoprogram adopt a policy such as:

• the next-oldest Python release if broad compatibility is required (e.g. minimum 3.7 while 3.6 still has upstream support)
• the next-newest Python release if cutting edge is desired (e.g. 3.8 while 3.9 is the newest release)
• all Python versions with upstream support (e.g. 3.6)
• a Python version supported by ReadTheDocs stable (e.g. 3.7)
• whatever Python is the default on major Linux distros (e.g. currently 3.7 for Debian stable). But admittedly, there can be too much concern for that. I've lost too much hair over trying to support whatever outdated versions RHEL/CentOS is shipping. Containers are a thing.

Thanks for the suggestions! What do you think about this proposal: Autoprogram must run on a version of Python that is guaranteed to be backwards-compatible with the oldest Python release that is still receiving security updates. According to PEP 387, this essentially means one that isn't more than two releases ahead of the oldest maintained version.

I think this strikes a nice balance between not requiring Autoprogram to run on really old Python versions while retaining the ability for users' projects to be written for such old versions.