What Python versions should Rope support?

[edreamleo]

I propose that Rope 1.x (The Python 3 version-only version of Rope) should support only Python 3.9 and above. My reasons:

• Imo, the Python 3.9 version of Python's ast module is significantly better than previous versions. My work on leoAst.py informs my opinion.

• Python 3.9 is already several years old. There should be no difficulty in installing it.

• Supporting only Python 3.9+ would simplify Rope's codebase. For example, a simplified version of the decorators property in pyobjectsdef.py is:

    @property
    def decorators(self):
        try:
            return self.ast_node.decorator_list
        except AttributeError:
            return getattr(self.ast_node, "decorators", None)

Unless I am mistaken, in Python 3.9+ this would become:

    @property
    def decorators(self):
        return self.ast_node.decorator_list

• These kinds of code simplifications would simplify testing. Testing only with Python 3.10 would probably suffice.

Your comments, please.

[lieryan]

The version of Python that rope supports is explicitly defined in the pyproject.toml and in the Github Actions.

But roughly, we follow the Python's Support Schedule. Rope supports any version of Python that is not yet reached its end of life status. Python 3.8 EOL is scheduled for 14 Oct 2024, so we'll need to retain 3.8 support until then, unfortunately.

Unlike end-user application like leo, rope is a library, so it cannot be choosy when it comes to what environment it is going to be installed into. Most large corporate projects are not going to be running the latest version of Python either, and large projects are the kind of projects that'll benefit the most from automated refactoring tools, so it's not really desirable to drop support for older Python versions too early.

[lieryan]

To provide some actual stats, https://pypistats.org/packages/rope

About 60% of rope users runs on Python <= 3.8

[lieryan]

Having said that, while we should maintain compatibility, we don't need to maintain feature parity between all versions of supported Python.

It's perfectly fine for some features to only exist in specific version of Python that had the appropriate ast support for it.

[edreamleo]

@lieryan Thanks for these comments.

Summary: Rope 1.0 will support:

• Python 3.7 until 2023/6.
• Python 3.8 until 2024/10.

A global search shows there are:

• 13 test cases decorated with only_for_versions_higher("3.10").
• No test cases decorated with only_for_versions_higher("3.9").
• 13 test cases decorated with only_for_versions_higher("3.8").
• No test cases decorated with only_for_versions_higher("3.7")

All other only_for_versions_higher decorators could be removed.

[lieryan]

Hi @edreamleo, I am not quite sure what you really mean when you keep saying Rope 1.0, when Rope already have released a 1.0 version for a very long time. It's confusing for other people that might be reading these in the future. What do you mean exactly by "Rope 1.0"?

And just to be clear, 3.7 can only be dropped by June next year. We don't drop support earlier than Python itself does.

[edreamleo]

@lieryan My apologies for the confusion. What I meant by 1.0 was the release that supports only Python 3. What is the correct term?

[lieryan]

Ah I see where the confusion comes now. There is a Rope version that still supports Python 2 that uses the 0.x versioning, but we no longer support that, nothing is going to get into that branch. Maybe if someone really needed to use Python 2, and there is an extremely critical bug, and they make a PR that is small and simple enough to just approve quickly, and I'm on a very good mood, maybe, just maybe, I might merge that PR into Python 2 version and make a special 0.x release. But that's very, very unlikely to happen; for most intents and purpose, the Python 2/Rope 0.x branch is basically already dead, as dead as a Blue Norwegian parrot that's been nailed to its perch.

So unless specified otherwise, the only active development branch of Rope is master, which only supports Python 3 and specifically master will only support non-EOL Python. So, rather than calling it Rope 1.0, which is confusing because it specifically refers to the 1.0 release, just leave the specifier out.

If you are in a thread of discussion that specifically must distinguish the legacy Python 2 and Python 3 branch, then maybe use the term Rope 1.x vs 0.x. Instead of 1.0 which can be interpreted that you might be talking about 1.0.0 release as if it's something that's going to happen in the future (when it's a version that's already well in the past), 1.x unambiguously means the next release of rope at the time of discussion.

[edreamleo]

@lieryan Thanks for the clarification. From now on I'll refer to the 1.x release, or python3-only code.