Repository navigation
Support Python 3.3+ #57
Description
Modernize rope to install and run on Python 3 versions 3.3 and newer. See python-future (prefered) or six for a single-codebase route to support Python 2 and Python 3.
Modernize rope to install and run on Python 3 versions 3.3 and newer. See python-future (prefered) or six for a single-codebase route to support Python 2 and Python 3.
Activity
alflanagan commentedon Jul 1, 2014
It looks like rope_py3k never got moved from bitbucket [https://bitbucket.org/zjes/rope_py3k].
gotgenes commentedon Jul 1, 2014
Correct. The rope project and the rope_py3k have incompatible repositories (even to the point of different tooling, rope using Git, rope_py3k using Mercurial). At this point, they are separate projects. Changes "upstream" here would be very difficult to transfer to rope_py3k. Furthermore, rope_py3k seems to be incompatible with rope. It was not started as a single-codebase effort but instead as a fork that runs on Python 3. Changes rope_py3k could never be back-ported to rope (which only runs on Python 2).
Popular projects have had much better support taking a single-codebase approach, usually with futures or six. For one, it means that – unlike the case for rope right now – there aren't two separate packages on PyPI: one for Python 2 and one for Python 3. Django users, for example, do not do
pip install Django_py3kwhen they want a version of Django that works for Python 3 andpip install Djangowhen they want a version that works on Python 2; they just dopip install Django, regardless of whether it's Python 2, Python 3, PyPy, or whatever interpreter it is that they choose. Since there will be no Python 2.8, rope's future is one that includes full Python 3 support.aligrudi commentedon Jul 2, 2014
Chris Lasher notifications@github.com wrote:
What makes rope different from most other python projects is
that it depends on the AST generated by python's compile()
function. This alters not only the syntax of rope's statements
but their logic.
I believe merging the two branches is possible, but requires
a motivated contributor. Or maybe we can designate rope_py3k
as the official branch, if python 3.x is more popular.
mcepl commentedon Jul 3, 2014
First, I completely agree (of course) with what @aligrudi says .. rope's situation is a magnitude more complicated, because we don't have to survive differences between two languages like Django, but we have to actively understand them and deal with them. It is even worse (see https://groups.google.com/forum/#!searchin/rope-dev/py3k for plenty of discussion on the topic), because
py3kis a bit in the state of flux, and py3.2, py3.3, py3.4 (not mentionning still cooking py3.5 and obsolete py3.1 and py3.0) are bit different so they (apparently) require slight difference in the analysis.Second. The problem is that we don't have REAL maintainer. I have stood up just to keep pieces together and make sure that patches are applied, questions answered, etc., but I don't have neither time nor frankly abilities to do real development on the rope codebase. I may fix a bug from to time, but to sit down and spend a significant amount of time on large project like this one, I cannot do. If anybody wants to make this happen (and I would love to see it happen, because without this rope will sooner or later die as an interest in py2k eventually dies), then I would need a patch. Or if anybody wants to stand up and take over mainternership, I am more than willing to pass the vessel.
alflanagan commentedon Jul 3, 2014
mcepl: Thanks for the update, explanations, and your work on rope_py3k. The point about the difficulty is well taken. I wish I had the expertise and time to volunteer as maintainer -- maybe once I get the youngster off to college.
gotgenes commentedon Jul 3, 2014
As far as I can tell from the list of accepted and in-review PEPs and the official "What's New" documents for Python 3-dev, Python 3.3 is the last release in the near future that will include new syntax. 3.4 released with no new syntax, and 3.5 has no planned new syntax. I think it's quite fair for the rope project to only target Python 3 at v3.3 and newer
Further, a fair amount of Python 3 syntax was backported to Python 2.7. Python 3.3 also re-introduced
u-prefixed strings for Unicode, as well (as a no-op), to smooth the Python 2 to 3 transition. If the rope project decides to target 2.7 and 3.3+, there is a lot of convergence, really.That's a fair problem. This issue is a long-term support request and an effort to spark discussion and put rope on a good track for Python 3 support. I did not expect Python 3 support to get implemented immediately.
Many thanks to you and others who volunteer whatever time they can to the project. You do an honorable deed.
paparomeo commentedon Sep 24, 2014
Although it seems like a daunting task, I am going to take a stab at merging rope_py3k and rope. I think that's the best bet on rope's future. I'll be using future as the compatibility layer and try to abstract all the Python 2.7/3.3+ AST differences as cleanly as possible. Does everyone agree that Python 2.7/3.3+ should be the target? As @gotgenes mentions, I believe that will simplify the job a lot.
mcepl commentedon Sep 24, 2014
@pmcnr go for it, but I am afraid that incompatibility between py2k and py3k for the coding of the rope will be the least of your problems.
paparomeo commentedon Sep 24, 2014
I am aware that 2.7/3.3+ language syntax differences and in the AST will be the most complicated aspect of this merge. I still believe there will be more common code than not, and the differences can be properly abstracted away. If it proves too complicated I think the best idea will be to leave the rope (py2) project in maintenance mode and make rope_py3k the focus of new development.
mcepl commentedon Sep 24, 2014
@pmcnr By any means, I don't want to discourage you from trying! You are right, that this is probably the only alternative how to make rope survive at all. Good luck!
hayd commentedon Apr 23, 2015
Is this still in the air?
To get the ball rolling... I had a quick go towards py 2 and 3 compatibility in #115. Whilst the tests don't pass python 3 yet, they at least run. I think they are pretty non-intrusive changes, no dependencies and they don't break python 2.
gotgenes commentedon Apr 23, 2015
Some other overlapping projects would be baron and/or redbaron. One interesting thing is PyCQA/baron#61, which posits lib2to3 could be used to span both Python 2 and Python 3 syntax trees.
hayd commentedon Apr 23, 2015
@gotgenes interesting! yapf uses lib2to3 to make a similar F-ishST (ast + spliced in comments).
Psycojoker commentedon Apr 24, 2015
Hello (baron author's here),
Another option you might want to consider is to take a look at what jedi is doing right now. The author is writing a parser also based on lib2to3 (which might already be finished) with a scope way closer to what rope is trying to achieved (adding static analysis to the python AST).
On my side I haven't had the time to explore the lib2to3 path since I'm horribly busy with other project. But, AFAIK, lib2to3 is the most powerful, solid, optimized and supported AST that works for both python 2 and 3 available right now. It's in the standard python lib and has been written by Guido himself.
One interesting point that came out of all similar discussion that I've had with people of jedi and astroid (pylint) is that we are all basically try to build our own AST (from scratch of from python's one) and that is would be very interesting to try to create a common base for all of us to avoid reinventing the wheel all the time, especially since it's a tedious task (but I don't know if Baron would fit here, I have very special needs).
Cheers,
gotgenes commentedon Apr 24, 2015
Great to have a reply from you, @Psycojoker! Where is this discussion taking place?
Psycojoker commentedon Apr 24, 2015
My bad, totally forgot the links in my previous post.
The mail from the jedi author talking about his works: https://mail.python.org/pipermail/code-quality/2014-November/000382.html
This was in the first thread of this month on the "code-quality" mailing list: https://mail.python.org/pipermail/code-quality/2014-November/thread.html#382 "RedBaron, a bottom-up refactoring lib/tool for python".
You can subscribe here: https://mail.python.org/mailman/listinfo/code-quality
anarcat commentedon Oct 1, 2015
it seems there was some progress here... does rope work with python3 yet? in 0.10.2, i get errors if only with the print() function...
emacsway commentedon Jan 9, 2016
I've added some Py3k fixes in #133 . Currently remains only failures=50, errors=40