Dynamic Language IDEs: Aptana Pydev and DLTK Python
This news item belongs to our series about IDEs for dynamic languages, other parts can be found through the DynamicLanguageIDEs tag.
Most dynamic languages IDEs share the same difficulties, so it might be interesting to see what others are doing; therefore, besides Ruby, this time we take a look at Python, a language not that different from Ruby.
Aptana keeps strengthening its position in the IDE market. After taking over the development of RadRails from its creators Matt Kent and Kyle Shank, they are now also the employer of Fabio Zadrozny, the main developer of of Pydev, the Eclipse based Python IDE:
We are very excited to announce that Pydev, the popular Python and Jython IDE, is now part of the Aptana product family and that Pydev creator, Fabio Zadronzy, will head up continued efforts to advance Pydev as part of the Aptana team.
We caught up with Fabio to learn about the current state and the future of Pydev. We asked him what distinguishing Pydev from other IDEs:
I'm probably a bit partial to answer that, but I guess that the code-intelligence features such as code-completions are pretty nice, and if you include Pydev Extensions, it's code-analysis is something I don't know how python coders can live without it (and of course there's also debugging, the newly added interactive console, find definition, editor features, etc). Being in the Eclipse ecosystem also helps, as users can benefit from the work done in many other projects, such as Subversive, Mylyn...
Now that Pydev is an Aptana product, will anything change for its users? And for people not interested in Aptana's other products, will Pydev still be available in a stand-alone IDE?
I think that this will enable Pydev to keep growing with the same level of quality and the same level of support that's been offered until now, because as the number of Pydev users keep growing, it's been increasingly difficult to maintain it by myself (note that others contribute with it from time to time, but until now, there's no one else that's developing/giving support to it steadily).
And yes, it'll still be available as a stand-alone Python-only IDE and will be able to work outside of Aptana Studio.
Pydev uses its own parser, which was derived from Jython and complemented with updates for newer Python versions. Now that Jython 2.5 has a new ANTLR based parser, are there any plans to migrate Pydev?
Not really... The Pydev parser actually needs much more info than Jython does (for the refactoring), so, that code was actually forked (and has much more work on it to provide that info). Also, in speed terms, after doing some profilings, it turns out that the Pydev parser is still faster than the Jython parser (even gathering more info -- and the parsing speed is really important in Pydev).
What features are planned for Pydev's future?
Usually, I don't plan the features much in advance... When it's time to get them, I go looking in the feature requests and try to gather the ones that I feel are more useful (and more requested). Right now I'm working on supporting Eclipse versions 3.2 to 3.4 (and making sure that all that's already there still works).
An interesting feature of Pydev is its refactoring support. We talked to Robin Stocker and Reto Schüttel, the team that implemented and extended most of the refactorings during a term project.
What refactorings do you provide?
We implemented the following refactorings and generators in our project:
- Generate Docstring
- Inline Local Variable
- Extract Local Variable
- Rename Local Variable
- Rename Method
- Rename Attribute
- Rename Class
How intelligent are they? Can't I just use search/replace?
You could use search and replace, but you would have to look at the code at each search result and decide whether it has to be renamed or not. Also, search and replace involving many files is pretty tedious.
For example, if you would like to rename the method "solve" of the "Puzzle" class, you wouldn't want to rename the "solver" variables you also have in the code nor the "solve" method of the "Solver" class.
Our rename refactorings is pretty intelligent, as it looks at the code and tries to understand it and then decide whether something has to be renamed or not. It would see that the "solver" variables have nothing to do with the "solve" method and also that some calls of "solve" belong to the "Solver" class and therefore shouldn't be renamed.
In order to make such intelligent decisions we implemented a type inference system for Python. It is based on the same algorithm that the DLTK people use in their Ruby IDE.
Most of the new refactorings have already been merged back to Pydev. Are there plans for the future?
In our follow-up project we extracted the type inference engine and turned it into an independent project to extend and improve it so that it is also usable for other purposes.
The next step now would be to reintegrate the improved type inference engine back into Pydev so that the refactorings can profit from these improvements. But we don't know when we can get to that as we both are pretty busy with other work.
The DLTK supports Python as well, but its still in the incubation state. The project lead Andrey Platov explains, what this means:
This means there are no active developers working on Python, and the level of DLTK Python is far from say Ruby level, so this "incubation" word is just a marker telling "hey, this thing is cooking and please do not consider it as a ready to use IDE"
[...] it would be great if Python component would stay in same line with Ruby and TCL. But we have no resources to do this. As for proof-of-concept, yes we kept this in mind initially, but now there are enough different languages implemented on top of DLTK, so I've no doubts: Python IDE would seamlessly fit into DLTK infrastructure.
This news item is part of our ongoing series about dynamic language IDEs. The other parts can be found under the DynamicLanguageIDEs tag at InfoQ.
Dmytro Svarytsevych Oct 30, 2014