On 6/6/07, Stani's Python Editor <[EMAIL PROTECTED]> wrote:
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?
Much like Stani said, since Python is interpreted, collection of possible completions splits into two methods: 1) source code analysis 2) dynamic introspection Of course, we could do either or a combination of both. IDLE just uses introspection: since IDLE always has a python shell running, it just completes according to the shell's state (plus built-in keywords and modules). This is a very simple method, obviously lacking. It does allow the user some control of the completion, though - just import whatever you want to be completable in the shell. However, introspection is all that is needed in a Python shell, which is the major reason this is the method used in IDLE. - Tal
