#914 Type inference engine, only one level deep


System: Windows XP
Eclipse version: 3.4.2
Pydev version: 1.4.6 (2273)
Eclipse install location: C:\eclipse-j2ee.3.4.2
Project location where the bug appears: C:\myworkspace\PPComWebTester
Jython: 2.2.1

Related to previous bug:

The following code now works in Pydev after previous bug fix:

from java.lang.Boolean import TYPE
print TYPE.name

However the following should also work but produces an error:

from net.grinder.script.Grinder import grinder
log = grinder.logger.output

Code completion is available in the grinder object and it is possible to select "logger" from the supplied list (or getLogger()).
However, once at this point code completion does not offer any choices for the logger object and "output" will be marked with an "Undefined varibale from import" error.

Regardless of whether I use "grinder.logger" or "grinder.getLogger()" the result is the same.
It appears that code completion is only one level deep once the static "grinder" object is imported.

This code runs fine via the jython shell.


  • Ross Nicholson

    Ross Nicholson - 2009-05-11
    • priority: 5 --> 9
  • Ross Nicholson

    Ross Nicholson - 2009-05-21

    Hi Fabio, did you find any time to have a look at this one? I ask because I have several developers coming in next month and would like them to be using pydev.



  • Fabio Zadrozny

    Fabio Zadrozny - 2009-06-15
    • status: open --> closed-fixed
  • Fabio Zadrozny

    Fabio Zadrozny - 2009-06-15

    Ok, fixed it partially (for pydev 1.4.7 svn: 2812).

    It's only partially because it won't work well with grinder.logger (but will work with grinder.getLogger()).

    The problem is that when it comes to code completing for java, I just pass the control to the java plugin (JDT), with a request for "net.grinder.script.Grinder.grinder.logger" and java itself doesn't know that for each getLogger a property logger should be instead, and I know of no way to actually add that at the JDT level... (but it does know about "net.grinder.script.Grinder.grinder.getLogger()").

    One option could be 'knowing' that the net.grinder.script.Grinder.grinder.logger should actually be net.grinder.script.Grinder.grinder.getLogger(), but then I'd have to go for each step to see if any of those could be a method instead of an actual attribute (i.e.: Check net.grinder.script.getGrinder() then net.grinder.script.Grinder.getGrinder() then net.grinder.script.Grinder.grinder.getLogger() and so on (which would end up being very slow).

    So, unless there's a better suggestion on how to handle that, this won't be added to pydev..




Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks