Re: [Pydev-code] Add 'global functions' to PyDev analyzer
Brought to you by:
fabioz
From: Andreas P. <an...@fr...> - 2013-08-14 10:18:03
|
Hi Fabio, On 2013-07-23 13:39, Fabio Zadrozny wrote: > On Tue, Jul 23, 2013 at 4:46 AM, Andreas Pakulat > <an...@fr...> wrote: >> 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. There are a few more technical details involved that cannot be easily changed which make it a bit harder to turn the tool into something that can just run python code as-is. Howerver I now realized that even that will not be sufficient to fully support our usecase. Squish tests are naturally running on a particular application that is to be tested. In various of the Squish editions we expose the complete internals of the Application (or rather the UI toolkit used) to the script side. This means a user testing an Eclipse application has full access to the Java and Eclipse API and can write code like this in his scripts: mystr = java_lang_String("Hello World") findObject("Shell").setText(mystr) And the binding of these classes, modules and functions is only done once an application is actually started. In addition the binding is somewhat dynamic, so if the application loads additional code lazily then Squish will only know about that once the code is actually loaded. This is as far as I can see not really supportable, so I now went the route of simply moving errors being reported by PyDev to warnings so our users scripts don't have 90% of their lines flagged in red :) Thanks for the tips though, we be able to use them to make at least some of the problems go away in the future provided the user has the application running. Andreas -- Andreas Pakulat sq...@fr... froglogic GmbH - Automated UI and Web Testing |