Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
First of all, I would like to thank fabioz for all the work he has done on Pydev. I continue recommending Pydev to others as the best open source Python IDE available.
Nevertheless, I do have several issues that bug me every single day I use it. I would like to hear which one of these I should open as issues in the tracker and which ones have no hope of getting rectified.
So, here goes, in order of annoyance factor:
1. Pydev does not see namespace packages properly (ie. "paste" of Paste Deploy, Pastescript and Paste) and considers them unresolved imports.
2. Code formatting messes up signed numbers ("-1" turns into "- 1").
3. Autocompletion for many standard library functions does not work. Try autocompleting partial (from functools) or asctime (from time). Isn't this the entire point of specifying forced built-ins in the interpreter configuration?
4. There seems to be no way to get rid of error markers coming from imports that work but cannot be seen through static analysis of the code (ie. from nose.tools import assert_raises), at least not without entirely disabling import errors.
5. By default, and contrary to popular conventions, Pydev adds an "src" directory and marks that as the only source directory. Most Python projects host their packages directly in project root. How many projects can you really find that have an src directory? I don't think I've yet seen one in the wild.
6. The interactive interpreter does not respond correctly to arrow key presses. If I press "up", I expect to get the previous entered line, or failing that, no action. Instead, my cursor moves one line up. The same goes for other arrow keys.
7. When the project is cleaned up, error markers that get removed leave the red squiggly lines in the code behind. This applies to warnings too.
8. In Jython projects, Pydev does not recognize static Java imports such as imports of inner classes or enum values and considers them unresolved imports.
9. There is no "rename module" functionalityin Pydev, so if you rename a module and forget to add the .py extension, you end up with an extensionless file. No biggie, but annoying nonetheless, since JDT handles this just fine.
10. Jython 2.5 grammar is slightly different from the CPython 2.5 grammar, but Pydev does not support this. Jython 2.5 supports class decorators and allows the use of the print keyword in imports (due to javax.print.* etc.). My request for supporting this was flat out rejected.
11. The nose test runner does not display the list of unit tests beforehand, despite this being supported in nose (nosetests -collect-only -v).
12. Pydev does not utilize the Java build path entries for import resolution in joint Java/Jython projects (where a PythonInterpreter is used from the Java application), so I have to add them separately to the project's Python configuration to get rid of the error markers (this is not necessary for running, that works fine).
Hi there, thanks for the review… would you mind adding error reports for those? If they stay only here in the forum they'll end up getting lost - and if I enter it for you, I won't be able to ask more things about it :)
Still, some notes:
1. Can you give an example? (I just installed paste - i.e.: easy_install paste - and it seemed to work for me, so, an example of what's failing would be nice when you create the bug report).
3. Actually, the whole point is asking the code to be analyzed through a shell in runtime, but yes, I agree it could ask for all the modules beforehand and create stubs and cache it for you (although that's something that's slow - which is the main reason it still isn't done)
4. Please create bug reports with the cases you encounter, as those probably have to be dealt for each specific situation…
5. Ok (should probably be a choice on whether to create the src folder or add the project root to the pythonpath - still, this should be a configuration, but note that you can still create it without the src folder and add the project itself as the pythonpath root).
6. Not sure here… it does that if the cursor is in the current line where text would be entered, and if you moved the cursor somewhere else, you probably want to do a copy/paste operation - then ctrl+end, arrow up for the completion (I really don't like the idea of having to use the mouse just to do a copy/paste operation).
7. This should be fixed in the latest nightly
10. Yes, I don't think adding platform specific hacks is something good (if each interpreter adds something different from the spec, that's something pretty bad as a whole, the Jython should do as the guys from CPython do when wrapping a library, changing print to print_, etc - still, if more people request this, I might consider adding it). As for the class decorators, using a newer version of a Python grammar should be enough for you (as class decorators are there in latest Python grammars).
11. I believe there's a report for that already…
12. Sorry, won't do that (I really don't want to add a stronger dependency to JDT). But if someone is willing to spend time studying the JDT api and keeping support over that as JDT evolves, I can apply a patch for it.
I've created the following issues:
#5 should probably have been filed at the feature requests compartment. I wasn't sure. Perhaps you can move it if necessary?
Regarding 3), is there a problem with that? The analysis only needs to be done once per interpreter (to collect the names from each built-in module) when the interpreter is added or when you reinitialize an interpreter (using "Apply").
Regarding 6), I reexamined the current behavior of the console and it seemed to work fine regarding up/down arrow keys. I really don't like the fact that selecting a piece of text moves the cursor too. No interactive console I've ever seen works this way. What also bugs me is that I can move the cursor on top of the prompt (>>>) with the left arrow key.
Regarding 10), I don't think Jython can rename packages in the JRE.
Regarding 12), what is your suggested approach for adding external dependencies where the exact path varies by developer? Java projects don't have this problem since you can define path substitution variables globally, independent of the project.
No problem with number 3 - it's just that it didn't get to the top of my priority, but it's getting closer ;-)
For 6, I understand your point (what you want is more a shell, which has 2 modes, one for copy/paste and another for the input). If you want you can add that as a feature request (but I must say it's not pretty high in the priorities overall)
For 10, actually, I think they could if they wanted… (I believe they have to make the whole wrapping to make things available for Jython - especially being in the import construct).
For 12, you can add a 'string substitution variable' on pydev, which is configured per-interpreter (a bit more flexible than global, as you can just change your interpreter and it'll get it, but if you have a variable that you really wanted to be global, you'll have to configure it in all interpreters)
Thanks, I didn't remember interpreters had their own string substitution variables.
Regarding 3), I added an issue: https://sourceforge.net/tracker/?func=detail&aid=3284991&group_id=85796&atid=577329
I'm bumping this because only one of these issues (#7) has been fixed. The rest remain a problem, especially #1. There's also a new problem concerning Java imports in Jython projects - imports from Java's standard libraries (java.*, javax.*) show error markers now, saying it can't find those classes. This was not an issue before.
Just fixed the issue on imports from Java standard libraries (most current nightly build)..
Good, but the rest of the issues remain. #1 is a constant PITA. Is there anything I can do to help you fix it?
#7 has done an encore - it was fixed in some build but reappeared a while later. Can you do something about it?
#7 now has a different behavior in the latest PyDev.
You can right-click any folder and choose PyDev > Remove Error markers to remove the existing errors, and PyDev will now by default only analyze open files and will remove error markers in the file when the editor is closed (so, in general, you should not have any errors there).
If you still want to force the analysis of a subtree, you may right-click a folder and choose PyDev > Code analysis.
I think you misunderstood. I know how the new code analysis works (or, rather, doesn't). Whenever it removes error markers, it should also remove the squiggly lines from the editor. It doesn't. This was the problem before and it is the problem now too.
Can you reproduce that reliably (I can't reproduce that here, so, it's probably another issue, not the one solved previously).
Which PyDev/Eclipse versions are you using?
Are those errors from the PyDev code analysis or from the PyLint code-analysis?
Version: Indigo Service Release 1
Build id: 20110916-0149
Yes, I can reproduce it 100% of the time. Edit a Python source file, type (1), save, press backspace, save , then type ) again and save. The error marker is removed, squiggly lines remain.
Humm, with the exact same steps, I can't reproduce it… Which platform are you in?
Linux (Kubuntu 11.10). Anything I can do to help with this (going to sleep now, will answer later if you have further questions)?
Ok, I've done a change which might fix it there (although I'm not sure as I couldn't really reproduce it here).
Will push a new nightly build in a couple of hours, so, please grab it tomorrow and let me know if it works for you.
With a quick try, I was unable to reproduce the issue anymore. Whatever you did seems to have worked! I'll be using PyDev throughout the day so I'll keep you posted if I come across it again. Thanks!
I realize this thread is old (well ancient really) but I was bored a while back and wanted to learn about eclipse plugins, so in search of a project I created a plugin,
https://github.com/Kbrowder/PyJDT that grabs JDT paths and adds them to pydev. In principle you could use the same techniques to integrate this into pydev directly (which would probably be significantly simpler, hindsight is an awful thing). Anyways this is basically what #12 wants.