On Fri, 13 Jan 2006, Russell Warren wrote:
> I've been getting what I consider to be a strange <opaque
> error> in the stack data view with some code that I'm working
> on. I've steadily hacked and slashed the code down to a
> reduced segment that still shows the problem (if not making
> much sense to look at). The code is at the end of this.
>> With a breakpoint at the last code line, what happens is that
> the fff object appears with the opaque error for some reason I
> don't understand. What is up here? It doesn't seem to match
> the description that exists in the help docs of the opaque
> error. This code works completely fine and I can even step
> through it all neatly in Wing.
>> Any explanation (or fix, so I can see the object) is
> appreciated!
The code sample you sent works fine for me. Try Clear Stored
Value Errors from the Debug menu. If you don't restart the debug
process, you'll also need to right-click on the value and Force
Reload.
What is going on here is that fff did at some point contain
something that Wing's debugger data value packaging code choked
on, and Wing remembers this to avoid trying to poke values that
act unexpectedly -- doing so can cause crashing (in buggy C
extension module code) or sometimes length hanging depending on
what is wrong with the user code being exercised by the debugger.
We've learned over the years that avoiding oddly behaving values
is the better course to take, although you can of course
un-ignored them with Clear Stored Value Errors.
This is kind of weird but it's unavoidable in the context of a
highly dynamic introspective language like Python. Fortunately
such problems also seem relatively rare in practice.
In this case, my guess is that at some point in your development,
__getattribute__ for '__dict__' returned something that was not a
dict, but it could have been something similar like an unusual
exception raised by __getattribute__.
Hope that helps to clarify it. If you figure out the specific
case that caused it, please let us know. There may still be
scenarios we can guard against more conservatively than just
giving up on the value.
Thanks,
Stephan Deibel
--
Wingware
Wing IDE for Python
Advancing Software Development
www.wingware.com