NetBeans Screenshot of the Week #33: Finding Unresolved Symbols

In my last entry I showed that the Fix Imports action will alert you to an unresolved symbol. This is really helpful since it can help you track down runtime problems.

Obviously, you shouldn't have to go run Fix Imports on every file, periodically, to look for unresolved symbols!

NetBeans has a special semantic checker for this. It is off by default, for two reasons:

  1. I added it just a couple of days ago - during the stabilization period for EA, so I didn't dare enable it in case it's seriously broken.
  2. There are cases where it doesn't yet work. I'll describe that later.

To enable it, open up the Editor options dialog, and under Hints, select Python. You should now see the current batch of Python hints. Enable the "Unresolved Symbol" hint:

Now let's open up the file again:

As you can see, the file is marked erroneous (by the red square above the scrollbar), and the scrollbar indicates where in the file the error is. Clicking on it to expose the error location you can see an underline under the unresolved symbol, and a tooltip explaining what the problem is. The error is also shown in the tasklist, so you don't have to open each file to look for problems - just let the tasklist scan your project for problems.

Here's another example. I opened up the Django 1.0 sources, and NetBeans pointed out this problem to me, in django.utils.simplejson.tool:

This shows that the import is unused, and that the attempts to call methods on the import do not work. The call would need to be changed to

obj = django.utils.simplejson.load(infile)

or the import changed to be

import django.utils.simplejson as simplejson

Here's one final one... Perhaps helpful to people having done a lot of Java development recently:

Finding unresolved symbols means that NetBeans must be able to find all the libraries you are importing. This means you can't just point NetBeans at a plain Python file - your project has to contain all the libraries you are using, and, you have to configure your source path correctly such that NetBeans computes the correct package names for your python modules. (I accidentally pointed to the "django" folder instead of its parent folder at first, which meant django. wasn't part of the package prefix and that meant that all kinds of symbols couldn't be resolved.)

Second, this won't work for dynamically generated symbols (eval etc). I haven't run into this a lot yet - but I'm sure there are areas where the unresolved detection can't find symbols that really do exist.

P.S. Is there a canonical Python term for what I've called "unresolved" here that we should use instead?


Very cool work. Use "undefined name".

Here's why. In Python, we never use the term "symbol", we would use "name". (FWIW, "symbol" is used in the parser module, but that's removed for 3.0.)

Two possibilities for "unresolved". The Python Reference Manual, section 4.1,, describes this names as being bound or not.

But I think more common usage is seen here in the Python shell:

>>> x
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined

So it probably makes more sense to say "undefined name". My last bit of intuition on this is that we typically say "bound" more for describing whether a method is bound or not.

Hope that helps!

Posted by Jim Baker on November 11, 2008 at 06:07 AM PST #

(on a side note this was posted to the netbeans google group but it looks like that group is nothing but an automated message collector so wanted to post here so Tor could see this)...

Tor, between Python additions how about integrating Ruby-Prof?
"I'm happy to announce the release of ruby-prof 0.7.0, the superfast,
open-source, Ruby profiler that helps you find bottlenecks in your
Ruby code.
The second major feature is significant internal changes that make it
easier to integrate ruby-prof with IDEs. ruby-prof is already being
used by Aptana's RadRails and has been integrated into the next
version of Code Gear's 3rd Rail. As part of this work, Hin has built a
user interface for ruby-prof that lets a user inspect individual
methods to see how much time they took as well as how they were

Posted by chess on November 12, 2008 at 07:04 AM PST #

Thanks for the pointing to the blog Jim. We are already tracking the RFE for Ruby Profiler:

I've added your comment there. But I guess we will not get it to 7.0.

Posted by Martin Krauskopf on November 12, 2008 at 08:12 AM PST #

Uh, sorry. I was confused, the thanks for the profiler links belongs to chess.

Posted by Martin Krauskopf on November 12, 2008 at 08:13 AM PST #

Post a Comment:
Comments are closed for this entry.

Tor Norbye


« July 2016