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-----
