New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Focus on Jedi, reduce Rope dependency #702
Comments
Hi, Jorgen. I respect you, but I think that your decision is emotional. Rope is excellent library, especially for refactoring. Many peoples uses rope. You can find in rope event commits of Bill Wendling from Google. I use rope too often. Now rope has some difficulties with number of real mantainers, but I think that it's temporary. +1 to retain the rope. |
Hello, and thank you for your comment. This has nothing to do with emotions, but is a simple result of the discussion on python-rope/rope#83 – I was told quite explicitly by the current Rope maintainer that Rope does not intend to make it possible for a library using it to distinguish between bugs in Rope and problems in the source code Rope is analyzing. That makes the library only marginally useful for code completion, on-the-fly documentation, or anything like that. Refactoring is the one feature in Rope I can still see useful. Do you see problems with using Jedi instead of Rope for these things? |
Yes, I was read python-rope/rope#83 .
First of all, I think, we should not be limited to single solution, and should have several alternatives. Sometimes I have problems with jedi, and thanks you for #763 - it's also actual for me. Very often I use refactoring by rope in my work (more info in chapter "Refactoring and Design" of "Refactoring" book by M.Fowler). Currently I use my patched rope with type hinting, because we have too many DIP in project. Until recently, I used jedi. Now I use more and more rope (my patched) for autocomplete, because it has well type hints for my case (supports for declaration of interfaces and class attributes). Also, rope has stable API and clean code (excellent codebase), which is easy to change. @aligrudi is a rare talent. |
Nice :-) Have you considered pushing those changes upstream? |
Thanks. Yes, there is pull request python-rope/rope#133 |
👍 |
I think it has a lot to do with emotions (mine and yours, I have apologized for my misspoke). In order to clarify my position (this seems to grown into pretty nice urban legend now) let me say three things:
Certainly I haven't said anything about closing issue reports without reading or any such stuff or not “to make it possible … to distinguish between bugs in Rope and problems in the source code Rope is analyzing” (not sure, what it even means). |
The problem I raised with you in that issue is that you do not distinguish between the error "invalid input" and "error in Rope". I have not asked you to fix broken code, to be able to parse broken code, or to do anything at all except to raise some Rope error "hey, your code is broken, go away" instead of some random Python errors. As long as you are unwilling to make that distinction, I am unwilling to support a library with such a broken API. |
I probably really just don't understand what you want? Could we get a pull request, or “Show me the code”, please? |
Jorgen Schäfernotifications@github.com wrote:
If I remember correctly, rope raises
|
As a user of the Rope library, Right now, the two cases are not distinguishable. I am afraid I can not "show you the code" for an API contract. |
In a discussion on a Rope issue, the current maintainer stated that Rope is not intended to work with source code that is not syntactically correct. That is, Rope is not meant to be used for as-you-type completion or quick call-tips, and any bugs Elpy users find in Rope will be closed as wontfix.
As these are the main features Elpy uses of Rope, we should simply focus on Jedi as a single backend and only optionally support Rope if it's installed.
The text was updated successfully, but these errors were encountered: