Hi Kai
Glad you're interested!
2015-04-30 19:46 GMT+02:00 Kay Hayen
Hello Dave,
Jedi has become quite powerful. If you're considering Jedi, I'm very happy to get you started. Let's talk!
The static analysis ignored, how does it compare to RedBaron when it comes to modifications and parsing of course code?
I don't know RedBaron very well. Its documentation states that it's still alpha and that Python 3 is not fully supported. That's different in Jedi. It's not alpha quality anymore, very well tested and supports Python 3 (not saying that RedBaron isn't well tested). Jedi uses a slightly modified lib2to3 internally, which is very much battle tested. Jedi also does error recovery. This is not something you __need__ for refactoring, but quite nice. I think the two tools are very similar. The biggest difference is probably static analysis, which you definitely need for certain refactorings. However Jedi definitely has fewer AST functions. The node/leaf objects of Jedi are at the moment quite simple. I'm willing to add functionality there, but only if it's used. Currently there's only the functions there that Jedi needs internally. To support the well known refactorings (e.g. inline/extract name/function), we might need to add a few methods there.
Does it provide a bounding box for code constructs?
I'm not really sure what you mean. Jedi knows the exact positions of objects. At the moment there's no method like RedBaron's `bounding_box`. Relative positions could be easily calculated with the current parser. However, I don't know what such a BoundingBox would be doing.
And the README just says "would in theory support re-factoring". Should that be rephrased. I was looking for example code that does it ...
You're probably right. I'm going to rephrase it. Refactoring was in an alpha state a few versions ago, when I removed support for it again, because the parser wasn't good enough. Now that I have replaced the parser, it should be much easier to implement it. Hope that was what you wanted to hear! ~ Dave