On 6/6/07, Tal Einat <[EMAIL PROTECTED]> wrote: > Hi all, (just joined the group) > > I've been developing IDLE over the past 2 years or so. Even before > that, I helped a friend of mine, Noam Raphael, write IDLE's > auto-completion, which is included in recent versions of IDLE. > > Noam wrote the original completion code from scratch, and AFAIK every > Python IDE which features code completion has done the same. Surely > there is -some- functionality which could be useful cross-IDE? > Retrieving possible completions from the namespace, for example. And > we should be learning from each-others' ideas and experiences. > > So how about we design a generic Python completion module, that > each IDE could extend, and use for the completion logic? > > - Tal >
Hi again everyone, Sorry for being away for such a long time. I hope we can get this conversation rolling again, and get started with the actual work. I'll try to sum up what has been said so far, and how I see things. == Top Priorities == * Can we implement a parser based on the standard Python AST compiler (or astng)? For example, can syntax errors be handled well? * Is importing reasonable security-wise? If not, can it be made secure? == General issues == * Do we aim for just completion, or also calltips? Perhaps also other meta-data, e.g. place defined, source code, ... (see IPython's '??') * Dependencies - do we want to allow C-extensions, or are we going for a Python-only solution? (IDLE would only use such a Python-only tool.) It seems that we want to pre-process most of the data in the background, so I don't see why we would want to do this in C for efficiency reasons. == Completion sources == 1) Importing "external" modules 2) Importing/Parsing "local" modules 3) Parsing the current file 4) Using objects/modules from the shell (e.g. IDLE has both editor windows and a Python shell) == Importing == * Stani mentioned that importing is problematic from a security point of view. What are the security issues? Are they really an issue for an IDE? If so, perhaps we could overcome this by importing in some kind of "sandbox"? * What are the pros and cons of Importing vs. Parsing? * If importing is always preferable to parsing unless there's a syntax error, perhaps try to import and parse on failure? == Parsing == * This is going to be the most complex method - I think we should have a general idea of how this should work before starting an implementation. I suggest hashing ideas out on a wiki, since there a lot of details to consider. * Can a parser based on the standard AST compiler (or astng) work? Is there a way to deal with errors? (HIGH PRIORITY!) * There are other existing, open-source implementations out there - WingIDE, PyPE have been mentioned. Any others? We should collect these so we can use the code for learning, and perhaps direct use (if possible license-wise). == Shell == This is relatively straight-forward - just use dir(). This should be optional, for use by IDEs which have a shell (support multiple shells?). Some known issues from IDLE and PyCrust: * Handle object proxies such as RPC proxies (e.g. RPyC) * Handle ZODB "ghost" objects * Watch out for circular references * Watch out for objects with special __getattr__/__hasattr__ implementations (for example xmlrpc, soap) == Persistence == * Stani mentioned a 'database'. I feel Sqlite should be at most optional, to reduce dependencies. * Do we really want to have the data persistent (between IDE sessiosns)? If so, we need to support simultaneous instances of the IDE so they don't corrupt the data. Any other issues? (I have a feeling this would better be left for later stages of development.) - Tal
