Re: [Pydev-code] Add 'global functions' to PyDev analyzer

[Andreas P. <an...@fr...>]

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