Hi Tal, To avoid spamming list membership needs to be approved. Of course I have approved ali, so he can participate on the list now. Good to see the discussion again rolling. Stani
Tal Einat schreef: > Here is a response from Rope's developer. > > (Stani, could you invite him to the group?) > > > ---------- Forwarded message ---------- > From: Ali Gholami Rudi <[EMAIL PROTECTED]> > Date: Aug 1, 2007 5:50 PM > Subject: Re: Python code completion module > To: Tal Einat <[EMAIL PROTECTED]> > > > Hi Tall: > > First of all I should note that rope's main goal was being a > refactoring tool and a refactoring tool needs to know a lot about > python modules. `rope.base` package provides information about python > modules. > > Actually what ropeide provides as auto-completion is defined in > `rope.ide.codeassist` module. This module almost does nothing but use > `rope.base`. Since `rope.ide` package is not included in the rope > library (which has been separated from ropeide since 0.6m4) it lacks > good documentation and the API might not be easy to use (most of it is > written in the first months of rope's birth). > >> ..., could you elaborate a bit on what kinds of completion Rope can >> do, ... > > I don't know what to say here. Well, actually it tries to use the > source code as much as possible and infer things from it. So I can > say that it can complete any obvious thing that can be inferred by a > human. Like this is the first parameter of a method and after dots > its attributes can appear or these modules are imported so their names > and contents are available or this is an instance of some known type > and we know its attributes and ... . Try ropeide (it uses emacs-like > keybinding, C-/ for completion; see ~/.rope if you want to change > that); it completes common cases (and sometimes completes things you > don't expect it to!). > >> ..., and the methods it uses? > > Rope analyzes python source code and AST. Rope used to use the > `compiler` module till 0.5 and now it uses `_ast` module. > >> We would especially like to know how your >> static and dynamic inference work, what they can accomplish > > There are a few examples in docs/overview.txt. Unit-test modules like > `ropetest.base.objectinfertest` and `advanced_oi_test` might help, > too. Also have a look at `rope.base.oi.__init__` pydoc for an > overview of how they work; (I'm afraid it is a bit out of date and > carelessly written.) The idea behind rope's object inference is to > guess what references (names in source-code) hold. They collect > information about code when they can and use them later. > >> ..., and what their limitations are. > > Many things in rope are approximations that might be exact if some > conditions hold. For instance rope might assume that every normal > reference in module scope holds only one kind of object. Apart from > these assumptions both SOI and DOI have their own disadvantages; For > instance SOI fails when dynamic code is evaluated while DOI does not. > Or DOI is slower than SOI. (Well, after recent enhancements to rope's > SOI I rarely use DOI). > > I tried to answer as short as possible. If there are questions on > specific parts of rope, I'll be happy to answer. > > By the way, I tried to reply this mail to the group, but it seems that > your group requires subscription for posting, so I've sent it to you, > instead. > > -- Ali > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFGsJ29ZS9c6evhANURAgvxAJ4rCPxQb8wtvPHasdFFkbyTBX4qAACgins8 > 9/LGzWb3F/0ck1bfEc6vQUU= > =b1Kf > -----END PGP SIGNATURE----- >
