Hi, A good point. I think we all have been thinking about this. Important issues for the design is the extraction method and the sources.
*the method* Importing is a lazy, but accurate way of importing, but is security wise not such a good idea. Parsing throught an AST compiler is better, however more difficult. Here are two options. >From version 2.5 the standard Python compiler converts internally the source code to an abstract syntax tree (AST) before producing the bytecode. So probably that is a good way to go as every python distribution has this battery included. As Nicolas suggested earlier on this mailing list, there is another option: the AST compiler in python or PyPy: On Mar 14 2006, 12:16 am, Nicolas Chauvat <[EMAIL PROTECTED]> wrote: > > WingIDE use anASTgenerator written in C (but cross-platform), > > lightningly quick, and open sourced. This could be a potential > > starting point. > > > Additionally isn't Python2.5 planned to have a C-written compiler? > > PyPy also produced an improved parser/compiler. > > http://codespeak.net/pypy/dist/pypy/doc/index.html > http://codespeak.net/pypy/dist/pypy/module/recparser/ But if it could be done with the standard one it is one dependency less. *the sources* In the design we could define first the sources: 1 external imported modules from the pythonpath 2 local modules relative to the current file or context dependent (Blender, Gimp, ...) 3 inner code For 1: It might be a good idea to have a function which scans all the modules from the pythonpath or one specific module to cache all autocompletion and calltip information of all classes, methods and doc strings. Why? Modules in the pythonpath don't change so often. With some criteria (file name, time stamp, size, ...) you could check if updates are necessary at startup. Having a readymade 'database' (could be python dictionary or sqlite database) for autocompletion/call tips would speed up things (and is also more secure if you are importing rather than parsing. For example trying to provide gtk autocompletion in a wxPython by importing is problematic). For 2: Here you load the parser on demand. Autocompletion/calltip information can be added to the database. For 3: A different kind of parser needs to be used here as per definition code you edit contains errors while typing. External modules are retrieved from 1 and 2, for internal code you can scan all the words and add them to the autocomplete database. As a refinement you can give special attention to 'self'. Also for calltips you can inherit when there are assignments, eg frame = Frame() than frame inherits autocomplete & calltip information from Frame. So autocompletion & calltips deals with two steps: extraction and 'database'. If someone has a good parser already, we could use it. Otherwise we can define an API for the extraction and maybe lazily implement it first with importing and concentrate first on the 'database'. When the database is ready we can implement the parsing. You could also implement the parsing first, but than it takes longer before you have results. Of course the library is GUI independent, it only works with strings or lists. What concerns SPE, it uses importing for autocompletion (1+2) and does internal code analysis for local code (however without the inheriting). Tal, how does IDLE's autocompletion works? Stani Tal Einat 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 >
