Cleanup Python 2-related code

[lieryan]

Figure out everything that's necessary to drop Python 2.7 support.

• Pin package in PyPI to block Python 2.7 users from upgrading to Rope version that's unsupported on it #454
• Migrate pytest.ini to pyproject.toml #450
• Update setup.py
• Remove outdated test cases
• Explore if we can use something like https://github.com/mbarkhau/lib3to6, https://github.com/nvbn/py-backwards, or simialr tools so rope codebase can be upgraded to Python 3 while still being able to run in Python 2.
• Explore non-stdlib parsers like parso or astroid.
• ... what else? ...

[climbus]

I think Rope can be helpful in migrating to Py3. Before dropping support, it would be good to fix major bugs.

[lieryan]

If a project is still running on Python 2.7 right now, it's probably safe to say that the project is not being actively developed. I doubt that there are that many people that are interested in doing major refactoring on such old code anyway. PyPI stats for rope shows that Rope 2.7 users hovers around 1-2%. This is in contrast to the global download stats, where 2.7 is quite a bit higher at around 7%. And I suspect a lot of those are probably automated CI installs with users that accidentally added rope to their production dependencies rather than actual users.

And many major distros are already dropping support to install Python 2.7, so users would have to not only their project on Python 2.7, which most people are likely going to do in a docker/VM setup; but also figure out how to set up Python 2.7 on their modern distro and text editors/IDE as well, and I doubt there are that many people that would bother.

lib2to3 would be a much better tool to assist with Python 2 to Python 3 migration anyway.

Dropping support for running Rope on 2.7 does not necessarily mean that Rope will completely break when refactoring 2.x project though. It just means that users would just use Python 3.x parser on their Python 2.7 code, which I think should probably be "mostly fine" (fingers crossed).

An idea is that we could add an option to refactor with Python 2.7 semantic. For example, in regards to list comprehension leaky variable scope and other such instances where Python 2.7 semantic differs from Python 3.x.

Syntax that now becomes invalid like print and exec statement, or try-except syntax is more tricky as Python 3.x parser will no longer parse them though. If this is a problem, there are two possible solutions:

1. We can either suggest the user to first run lib2to3 which will convert their code to use print function and add a __future__ import, which rope would then be able to work with using Python 3 parser.

2. Or if there are really big interest in Python 2.x support, then we can re-add support for Python 2.x parsing by integrating an external library parser, like astroid or parso rather than relying on standard library ast. That is a project that's worthwhile to consider on its own anyway even without considering 2.x support.

That way the supported workflow is that users run their editor tooling like rope on Python 3.x even when working on a Python 2.x project.

[lieryan]

The benefit of dropping support for running rope on Python 2.x is that rope codebase itself can start using more modern Python idioms and libraries.

Having said that, given what you said in the linked ticket, I don't think we need to be in a hurry to drop 2.7 support any time soon yet as currently the burden of keeping support is not actually that significant.

[climbus]

Exactly that's what i meant :)