Re: [Pydev-code] Add 'global functions' to PyDev analyzer
Brought to you by:
fabioz
From: Fabio Z. <fa...@es...> - 2013-07-23 11:40:08
|
On Tue, Jul 23, 2013 at 4:46 AM, Andreas Pakulat <an...@fr...>wrote: > Hi Fabio, > > thanks for the hint about the pycompletionserver.py. Currently we > already have a change or two to PyDev and roll our own but we would > rather use the official version. > > Unfortunately our interpreter is embedded into a commandline tool that > does not support being used like a normal python interpreter. So thats > why choosing it as an interpreter is not suitable at the moment. What > it does is basically load the main script file (i.e. parse it but does > not run it immediately), then add a few modules to the python > interpreter via C API, import those modules into the global namespace of > the main script file and also import several functions into the global > namespace. This was done as a convenience for the users but now clearly > bites back at us when trying to teach PyDev about these specialties. > Ok, so, it's not really a custom interpreter, just a different main... Not sure if that's the best approach (I'd probably go toward a more common approach of having a different main entry which then would run the script after configuring the environment, such as most web frameworks do or maybe a custom sitecustomize). Still, if you bundle it as an executable, it shouldn't be all that hard to make it look like a real python interpreter (i.e.: one that could really be used as an interpreter -- that way you wouldn't need to change PyDev at all and everything should just work). This is probably the preferred approach. Now, if that's difficult for you, the pycompletionserver.py/importsTipper.pyadjustment probably requires less fiddling to integrate. Regarding a better approach within PyDev itself, please create a feature request for that in https://sw-brainwy.rhcloud.com/tracker/PyDev/ (this is also a request web2py users have -- for which there's a discussed workaround detailed at the old tracker: http://sourceforge.net/p/pydev/feature-requests/534/). > > Its of course also possible to import those registered modules in the > script file or in one that is being imported into the main script. > > What I ended up doing now which seems to work with 2 caveats (see > further down) is that I'm using the extension points > pydev_interpreter_new_custom_entries, pydev_modules_observer and the > completion extension point. The first one registers the names of the > modules we add via the C API as 'builtins', the second one adds tokens > to the __builtin__ module for those modules and the functions we import > into the global namespace. It also populates our modules with their > functions when the PyDev code needs them (a script importing our squish > module for example). All this seems to avoid errors being flagged for > our Squish API, but does not yet provide the modules and functions for > completion. Hence using the completion extension point to support that. > > The two minor issues with this are: > > 1. For the builtins registration using the > pydev_interpreter_new_custom_entries extension point the users need to > remove and re-add the interpreter so that PyDev fetches the builtins > again. > > Maybe there's a way to do the above programatically upon startup of a > plugin? > > 2. When using 'import squish' in a script now a warning is flagged > about this shadowing a builtin module which is correct from what PyDev > knows but not really happening in the actual interpreter that executes > the tests. > > The second point is not much of a problem as its just a warning and > hence does not jump out at the user as much as an error (in particular > an error in script code that Squish just generated). > > Andreas > > > On 2013-07-22 22:39, Fabio Zadrozny wrote: > > Hi Andreas, > > > > Actually, if you really have a custom interpreter and this is added > > in its startup, it's strange that it doesn't work already (PyDev > > always spawns a shell for the completion and upon startup it'll load > > the __builtin__ -- or builtins -- module and do a dir() in it). > > > > So, if it's custom interpreter, it's mostly a matter of filling the > > __builtins__ at the startup... If that's not the case, you could > > change PyDev to add some custom code at the module scope at > > /org.python.pydev/pysrc/pycompletionserver.py (but you'll have to > > maintain your own fork if you choose this path). > > > > Cheers, > > > > Fabio > > > > On Fri, Jul 19, 2013 at 12:15 PM, Andreas Pakulat > > <an...@fr...> wrote: > > > >> Hi, > >> > >> I'm currently working on improving our usage of PyDev, in particular > >> starting to let PyDev not only syntax highlight but also analyze the > >> code our users write. Unfortunately this has one drawback, we use a > >> custom interpreter and add several global functions to it (this is > >> done > >> by having a module for these functions and then importing everything > >> from this module by default into the global namespace). > >> > >> I know about the setting for the PyDev analyzer to not show errors > >> on > >> certain undefined functions/variables, but the number of functions > >> makes > >> this single lineedit/preference pretty cumbersome to extend. > >> > >> I'm wondering wether there's a different way (via code maybe?) to > >> teach > >> PyDev about a list of functions it should consider to be > >> 'predefined', > >> similar to the builtin modules? > >> > >> I'm currently using PyDev 2.6, but could upgrade to 2.7.5 if that > >> makes > >> it easier to achieve what I want. > >> > >> Andreas > >> > >> -- > >> Andreas Pakulat sq...@fr... > >> froglogic GmbH - Automated UI and Web Testing > >> > >> > >> > ------------------------------------------------------------------------------ > >> See everything from the browser to the database with AppDynamics > >> Get end-to-end visibility with application monitoring from > >> AppDynamics > >> Isolate bottlenecks and diagnose root cause in seconds. > >> Start your free trial of AppDynamics Pro today! > >> > >> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > >> [1] > >> _______________________________________________ > >> pydev-code mailing list > >> pyd...@li... > >> https://lists.sourceforge.net/lists/listinfo/pydev-code [2] > > > > > > > > Links: > > ------ > > [1] > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk<http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk> > > [2] https://lists.sourceforge.net/lists/listinfo/pydev-code > > > > > > > ------------------------------------------------------------------------------ > > See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from > > AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > > > > _______________________________________________ > > pydev-code mailing list > > pyd...@li... > > https://lists.sourceforge.net/lists/listinfo/pydev-code > > -- > Andreas Pakulat sq...@fr... > froglogic GmbH - Automated UI and Web Testing > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > pydev-code mailing list > pyd...@li... > https://lists.sourceforge.net/lists/listinfo/pydev-code > |