On Tuesday 16 February 2010 14:33:19 Sylvain Thénault wrote: > On 16 février 06:33, Edward K. Ream wrote: > > Hi Edward, > > > > I am considering creating a project on launchpad to play with those > > > > ideas, called something like ekr-pylint. > > > > On second thought, this did not seem like a wise idea. Instead, I > > simply created a personal branch: > > lp:~edreamleo/+junk/new-pylint > > > > This is just a sandbox. It is public, but no one will see it unless > > they look hard for it :-) It has no chance to embarrass anyone. > > Great. I've to admit I prefer that than a fork. Regarding the work you > would like to do with pylint / astng, the best would probably to start > discuss about them on this mailing list. I've read your document, and > there are some things that are imo already like this or on the way to > become so. For instance, pylint is already generating ast for all files > it received as argument before starting the analysis. Also, Emile is > currently working on a big astng refactoring to provide our own > representation instead of monkey patching compiler/_ast. Emile, could > you publish your work in a branch of the astng repo and then we could > start discuss about it here, and maybe Edward could tell how it fits > his ideas.
I started refactoring astng this summer; first I reduced the monkey patching (september 2009). I am since november working on a branch called 'rebuild' which indeed creates our own nodes so that monkey patching should eventually disappear. It basically works except 5-6 tests. The main new stuff is in the modules _nodes_<ast/compiler>.py and rebuild.py . Things look much cleaner right now, and maybe the _proxied / __proxied problem could be handled easier. By the way, I absolutely agree with you that the inference code is difficult to understand. I am not sure, but I would imagine a mecanism that controles the inference by a class (probably something similar to a Visitor) that could catch infinite recursion and the like. Maybe you are right regarding to the exception mecanism that it is not the best way to handle it. I would also like to work without generators / yield; for me it would be much clearer if the inferred values would be collected in our Visitor / Walker, but I might be quite wrong about that. Also, I am very interested about your ideas: Pass 4: post-process pylint nodes and : Pass 5: dynamic analysis This is the fun/hard part. We want to infer the types that variables can have, and the types that functions (and classes with __call__ members) can have. Analyzing assignment statements is the big one. -- Emile Anclin <emile.anc...@logilab.fr> http://www.logilab.fr/ http://www.logilab.org/ Informatique scientifique & et gestion de connaissances _______________________________________________ Python-Projects mailing list Python-Projects@lists.logilab.org http://lists.logilab.org/mailman/listinfo/python-projects
