Debugging Help

wxPython Users
1

This is a general Python question, although I'm trying to debug the
wxPython GUI. What's a good on-line resource to ask for help using pdb? How's
the Usenet group?

   One of my data entry methods is not working as intended and I want to watch
the code perform. I imported pdb into the main module, then tried to run the
application from the command line as, 'python -m pdb eikos.py'. When the pdb
prompt appeared I entered a breakpoint in a different module, thusly:

(Pdb) b ScopingPage:123

which sets a breakpoint at line 123 of the ScopingPage.py module. Then I told
the application to run ('r'), expecting to see the UI displayed and the
application to run normally until the breakpoint was reached. No such luck.
The application continues running at the command line, no GUI appears, and I
soon get stuck at a place where 'n' (for next) produces nothing.

   I'd like to learn better how to use pdb with a multi-module Python
application where the error is in a UI method.

Thanks,

Rich

···

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

2

Take a look at winpdb. http://www.digitalpeers.com/pythondebugger/

David

···

-----Original Message-----
From: Rich Shepard [mailto:rshepard@appl-ecosys.com]
Sent: Thursday, December 08, 2005 11:41 AM
To: wxPython-users@lists.wxwidgets.org
Subject: [wxPython-users] Debugging Help

   This is a general Python question, although I'm trying to
debug the wxPython GUI. What's a good on-line resource to ask
for help using pdb? How's the Usenet group?

   One of my data entry methods is not working as intended
and I want to watch the code perform. I imported pdb into the
main module, then tried to run the application from the
command line as, 'python -m pdb eikos.py'. When the pdb
prompt appeared I entered a breakpoint in a different module, thusly:

(Pdb) b ScopingPage:123

which sets a breakpoint at line 123 of the ScopingPage.py
module. Then I told the application to run ('r'), expecting
to see the UI displayed and the application to run normally
until the breakpoint was reached. No such luck. The
application continues running at the command line, no GUI
appears, and I soon get stuck at a place where 'n' (for next)
produces nothing.

   I'd like to learn better how to use pdb with a
multi-module Python application where the error is in a UI method.

Thanks,

Rich

--
Richard B. Shepard, Ph.D. | Author of
"Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments
Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517
Fax: 503-667-8863

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail:
wxPython-users-help@lists.wxwidgets.org

3

Liberal print statements and error checking can offer 95% of what a
debugger gets you. The last 5% being the setting and clearing of
breakpoints during runtime.

- Josiah

···

Rich Shepard <rshepard@appl-ecosys.com> wrote:

   This is a general Python question, although I'm trying to debug the
wxPython GUI. What's a good on-line resource to ask for help using pdb? How's
the Usenet group?

   One of my data entry methods is not working as intended and I want to watch
the code perform. I imported pdb into the main module, then tried to run the
application from the command line as, 'python -m pdb eikos.py'. When the pdb
prompt appeared I entered a breakpoint in a different module, thusly:

(Pdb) b ScopingPage:123

which sets a breakpoint at line 123 of the ScopingPage.py module. Then I told
the application to run ('r'), expecting to see the UI displayed and the
application to run normally until the breakpoint was reached. No such luck.
The application continues running at the command line, no GUI appears, and I
soon get stuck at a place where 'n' (for next) produces nothing.

   I'd like to learn better how to use pdb with a multi-module Python
application where the error is in a UI method.

Thanks,

Rich

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

4

Hi Rich,

Just run the module you want to debug from within Boa, click on the line you are interested in a press F5 to set a breakpoint and then run it by clicking on the red arrow.

See you
Werner

Rich Shepard wrote:

···

  This is a general Python question, although I'm trying to debug the
wxPython GUI. What's a good on-line resource to ask for help using pdb? How's
the Usenet group?

  One of my data entry methods is not working as intended and I want to watch
the code perform. I imported pdb into the main module, then tried to run the
application from the command line as, 'python -m pdb eikos.py'. When the pdb
prompt appeared I entered a breakpoint in a different module, thusly:

(Pdb) b ScopingPage:123

which sets a breakpoint at line 123 of the ScopingPage.py module. Then I told
the application to run ('r'), expecting to see the UI displayed and the
application to run normally until the breakpoint was reached. No such luck.
The application continues running at the command line, no GUI appears, and I
soon get stuck at a place where 'n' (for next) produces nothing.

  I'd like to learn better how to use pdb with a multi-module Python
application where the error is in a UI method.

Thanks,

Rich

5

David,

   Thank you for the suggestion. That's not doing better than pdb,
unfortunately.

Rich

···

On Thu, 8 Dec 2005, David Woods wrote:

Take a look at winpdb. http://www.digitalpeers.com/pythondebugger/

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

6

Josiah,

   That's the way I used to debug FORTRAN code on the IBM S/360s. :slight_smile: With
pdb, I can 'p' to print the value of a variable and watch changes as the code
executes. My immediate problem seems to be that the breakpoint is not being
executed at the proper place. So, I'll put in a second one in the fuction
that is supposed to be called.

Thanks,

Rich

···

On Thu, 8 Dec 2005, Josiah Carlson wrote:

Liberal print statements and error checking can offer 95% of what a
debugger gets you. The last 5% being the setting and clearing of
breakpoints during runtime.

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

7

Werner,

   Thank you for the suggestion. The UI is defined in the main module, but the
code I want to debug is in another, imported, module. Trying to run that
latter module in boa does not work because the UI is not displayed.

Rich

···

On Thu, 8 Dec 2005, Werner F. Bruhin wrote:

Just run the module you want to debug from within Boa, click on the line
you are interested in a press F5 to set a breakpoint and then run it by
clicking on the red arrow.

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

8

> Liberal print statements and error checking can offer 95% of what a
> debugger gets you. The last 5% being the setting and clearing of
> breakpoints during runtime.

Josiah,

   That's the way I used to debug FORTRAN code on the IBM S/360s. :slight_smile: With
pdb, I can 'p' to print the value of a variable and watch changes as the code
executes. My immediate problem seems to be that the breakpoint is not being
executed at the proper place. So, I'll put in a second one in the fuction
that is supposed to be called.

Make that variable an instance variable on a class, and you can track
its value all you want with some metaclass and property magic. Though I
would understand not wanting to do it, sometimes it can get ugly*.

- Josiah

* Example implementation of an instance variable tracker. Could
probably also be done by subclassing dict, though dict subclassing may
not work in older Pythons.

def genproperty(name):
    nname = '__' + name
    def get(self):
        print "getting", name
        if nname in self.__dict__:
            return self.__dict__[nname]
        else:
            raise AttributeError(name)
    def set(self, value):
        print "setting", name, value
        self.__dict__[nname] = value
    def dele(self):
        print "deleting", name
        if nname in self.__dict__:
            del self.__dict__[nname]
        else:
            raise AttributeError(name)
    return property(get, set, dele, "property for %s"%name)

class TrackerType(type):
    def __new__(cls, name, bases, dct):
        vars = dct.get('vars', None)
        dct['__dict__'] = {}
        if vars:
            print "..."
            sl = dict.fromkeys(dct.get('__slots__', ))
            for var in vars:
                dct[var] = genproperty(var)
                sl[var] = None
            dct['__slots__'] = sl.keys()
        return type.__new__(cls, name, bases, dct)

class tracker(object):
    __metaclass__ = TrackerType
    vars = ['a', 'b']

t = tracker()
t.a = 1

setting a 1

t.a = 2

setting a 2

t.b

getting b
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 8, in get
AttributeError: b

t.b = 7

setting b 7

···

Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Thu, 8 Dec 2005, Josiah Carlson wrote:

9

Hi Rich,

Rich Shepard wrote:

Just run the module you want to debug from within Boa, click on the line
you are interested in a press F5 to set a breakpoint and then run it by
clicking on the red arrow.

Werner,

  Thank you for the suggestion. The UI is defined in the main module, but the
code I want to debug is in another, imported, module. Trying to run that
latter module in boa does not work because the UI is not displayed.

Boa doesn't care if there is a UI or not. Whatever it is it just has to run by itself or be called by something. So, set your breakpoint in the module and then run the main module all from within Boa.

See you
Werner

···

On Thu, 8 Dec 2005, Werner F. Bruhin wrote:

Rich

10

Werner,

   I had tried that, too, with the same results. I've just tried it again. The
code runs to the breakpoint (after the pdb.set_trace()) in the code), I then
selected the Step (F7) icon and the cursor moved down a line. Then nothing.
That icon was no longer active and I could not step through the code and
follow to the next method where a text entry dialog is called. Very strange.

Many thanks,

Rich

···

On Thu, 8 Dec 2005, Werner F. Bruhin wrote:

Boa doesn't care if there is a UI or not. Whatever it is it just has to
run by itself or be called by something. So, set your breakpoint in the
module and then run the main module all from within Boa.

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

11

Josiah,

   I need to study this so that I understand what it's doing.

Thanks,

Rich

···

On Thu, 8 Dec 2005, Josiah Carlson wrote:

Make that variable an instance variable on a class, and you can track its
value all you want with some metaclass and property magic. Though I would
understand not wanting to do it, sometimes it can get ugly*.

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

12

This is an interesting observation: I've not before tried to debug a GUI.
Everything I have written has run from the command line; even the WIMP
interfaces I wrote in C for DOS applications could be debugged with the
standard debugger.

   What I'm finding is that moving the focus from the running application to
the debugger window (in boa or winpdb) freezes the application. As soon as I
click on the "Add" button, I reach the breakpoint, but cannot step through
the method and have it generate the text entry dialog box.

   I know there are techniques I can learn ... perhaps more simple than
Josiah's latest offering.

Thanks all,

Rich

···

On Thu, 8 Dec 2005, Rich Shepard wrote:

This is a general Python question, although I'm trying to debug the
wxPython GUI. What's a good on-line resource to ask for help using pdb? How's
the Usenet group?

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

13

> This is a general Python question, although I'm trying to
debug the
> wxPython GUI. What's a good on-line resource to ask for help using
> pdb? How's the Usenet group?

   This is an interesting observation: I've not before tried
to debug a GUI. Everything I have written has run from the
command line; even the WIMP interfaces I wrote in C for DOS
applications could be debugged with the standard debugger.

   What I'm finding is that moving the focus from the running
application to the debugger window (in boa or winpdb) freezes
the application. As soon as I click on the "Add" button, I
reach the breakpoint, but cannot step through the method and
have it generate the text entry dialog box.

   I know there are techniques I can learn ... perhaps more
simple than Josiah's latest offering.

That's odd. I use winpdb to debug my GUI code without difficulty, including
dialog creation. You might try it on something you know works to get used
to it before trying it on something you're having trouble with.

David

14

David,

   OK. I'd sure like something that works. I had difficulty using winpdb, so
I'll play some more with it as soon as I finish a letter than must go out
today.

Thanks,

Rich

···

On Thu, 8 Dec 2005, David Woods wrote:

That's odd. I use winpdb to debug my GUI code without difficulty,
including dialog creation. You might try it on something you know works to
get used to it before trying it on something you're having trouble with.

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

15

David,

   OK. Got it fixed.

   I played with winpdb until I understood how it works, then I was able to
see where the problem was located, but not why. Looking at my code it finally
hit me: I made a really silly error. Twice. Correcting those errors solved
the problem.

   So I thank you for pointing out winpdb to me. Now that I see just what it's
doing I can use it more effectively. And, I learned a valuable wxPython
lesson too. What it is shall remain my secret, however, because that's the
way it is. :slight_smile:

Rich

···

On Thu, 8 Dec 2005, David Woods wrote:

That's odd. I use winpdb to debug my GUI code without difficulty,
including dialog creation. You might try it on something you know works to
get used to it before trying it on something you're having trouble with.

--
Richard B. Shepard, Ph.D. | Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM) | Impact Assessments Using Fuzzy Logic"
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

16

> Make that variable an instance variable on a class, and you can track its
> value all you want with some metaclass and property magic. Though I would
> understand not wanting to do it, sometimes it can get ugly*.

Josiah,

   I need to study this so that I understand what it's doing.

The standard document for learning about properties, metaclasses, etc.,
is: http://www.python.org/2.2/descrintro.html

The general rule of thumb is that if you have to use metaclasses to get
something simple done, you may be doing something that is more difficult
than it should be*.

- Josiah

* a quicker and easier implementation of a tracker, without using
metaclasses, properties, etc.

class tracker:
    def __setattr__(self, key, value):
        print "setting", key, value
        self.__dict__[key] = value
    
    def __getattr__(self, key):
        print "getting", key
        return self.__dict__[key]
    
    def __delattr__(self, key):
        print "deleting", key
        del self.__dict__[key]

foo = tracker()
foo.a = 5

setting a 5

del foo.a

deleting a

···

Rich Shepard <rshepard@appl-ecosys.com> wrote:

On Thu, 8 Dec 2005, Josiah Carlson wrote:

17

This thread triggered a thought I'd like to brainstorm a bit on.

I've become a fan of test-driven development (see http://www.agiledata.org/essays/tdd.html for an introduction; there are other good URLs as well). One reason for this is that it encourages you to develop and test a little bit at a time, at each increment adding just a small amount to a well-tested foundation; I've discovered how quickly and surely you can develop solid code once you've got things set up properly.

One problem with TDD comes when you're testing chunks of code that aren't self-contained. One example of this is code that accesses a database; another is UI code, which is typically driven by a framework like wxPython. For the database case, it's become common practice to use a "mock object" to act in place of a database connection; the mock object implements just enough of the DB connection protocol to make the test work. (http://www.martinfowler.com/articles/mocksArentStubs.html gives a nice discussion and some examples. More information is at http://c2.com/cgi/wiki?MockObject.)

One helpful organizational technique in this case is to use a design pattern, such as Model-View-Controller, that leaves as little code as possible in the classes closest to the framework. This allows doing TDD on the Model, for instance, while leaving wxPython entirely out of the picture; the test framework acts as both the View and Controller.

It occured to me that it might be possible, and worth it, to create a library of mock classes to take the place of the wx classes for TDD. A mock class for wx.TextCtrl, for example, might allow the tester to set expectations for the initial content and provide for a list of events to generate, along with expected method calls on the mock object in response to each event.
A somewhat similar idea is pursued in the "Testing the User Interface" section of http://www.codeproject.com/dotnet/tdd_in_dotnet.asp.

This may be a bit dense, but I did want to get it down and out there, even though I don't have time to flesh it out. I'll be happy to discuss it.

Don Dwiggins
Advanced Publishing Technology