[code-quality] RedBaron, a bottom-up refactoring lib/tool for python

[Dave Halter]

Sylvain,

2014-11-17 10:01 GMT+01:00 Sylvain Thénault <sylvain.thenault at logilab.fr>:

> On 15 novembre 16:49, Dave Halter wrote:
> > Hi Laurent
>
> Hi Laurent, David,
>
> > Great to see somebody finally tackling refactoring.
>
> indeed!
>
> > I'm answering, because I think we're working on the same issue. But we
> have
> > finished two different parts: You have finished a refactoring
> > implementation and I have finished the static analysis part. I'm the
> author
> > of Jedi. https://github.com/davidhalter/jedi/
>
> Could I ask what do you mean by static analysis in the context of a
> completion
> library?
>

Not the "linting" part. The name resolution/tuple assignment/function
execution part. I assumed he meant that when he talked about using rope or
astroid for static analysis.
Jedi's static analysis part is not much further than what I showed at
EuroPython, because I'm currently rewriting the parser stuff.

>
> > I'm currently working on the integration of the lib2to3 parser into Jedi.
> > This would make refactoring really easy (I'm about 50% done with the
> > parser). It's also well tested and offers a few other advantages.
> >
> > In a perfect world, we could now combine our projects :-) I will look in
> > detail at Red Baron on Monday.
>
> David, we've been talking about this during the latest EuroPython, and I've
> talked with Laurent yesterday at the Capitole du Libre in Toulouse: IMO we
> could
> start by extracting from lib2to3 "the" parser that could be used by every
> tools
> like ours (refactoring, completion, static analysis...). It would be:
> * loss-less (comments, indents...)
> * accurate (eg from/to line numbers)
> * fast
> * version agnostic within a reasonable frame (eg 2.7 -> 3.4?)
>

Yes, that's what I'm trying to create now (based on lib2to3). However my
biggest problem is that I have to rewrite my evaluation engine as well,
because it was depending on the old parser. I have two additional
constraints:

- decent error recovery
- memory efficient

The "fast" part is something I'm very eager to implement. I have done this
before with my old parser. My approach is to re-parse only the parts of the
file that have changed.
My idea of "version agnostic" is to have the parser and the evaluation
engine try to adhere to one version. My goal is to give Jedi a Python
version number and Jedi would work according to that. This would make
linting really cool, because you can run the linter for different Python
versions.

I would recommend you to wait until I have finished my parser (1-2 months)
or can at least report back. You can then either take the parser and fork
it or take the evaluation engine as well.

~ Dave

>
> I guess almost every one on this list would be interested in such a
> parser, even
> if most would have to do a second pass on the generated tree to get more
> "business oriented" tree for their own project. Whatever, we (pylint guys)
> would
> be greatly interested.
>
> --
> Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse
> (05.62.17.16.42)
> Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
> Développement logiciel sur mesure:       http://www.logilab.fr/services
> CubicWeb, the semantic web framework:    http://www.cubicweb.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/code-quality/attachments/20141117/fbdd2c4a/attachment.html>