On 5/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > How can we step through the TurboGears Python code? > > you could start with http://docs.python.org/lib/module-pdb.html > Hmm, I am looking for a UI-based debugger, but probably there is a way > to pu WinPdb over the module-pdb. Just one quick newbie question: did > anybody see this module-pdb working with exactly TurboGears? :)
I haven't tried it on TurboGears code yet, but last time I needed this, I used HAP (http://hapdebugger.sf.net). It hasn't been updated in a while, but the source code was clean enough that it was very easy to customize for our needs. > > > If TurboGears wants to reach the big audience (and it definitely > > > wants) the debugging methods for Windows are a must. > > Why windows? you need that for all OS. > > Because Windows is a mass market :) I think some of the confusion here comes from the differing development styles on UNIX and Windows. In my experience, the practice of always stepping through code in a source-level debugger is much, much more common than it is among UNIX developers. For example, some Windows shops have a rule that ALL procedural code must be stepped-through in a debugger before checkin. So it's not just that Windows is a "mass market": the "mass market" of Windows developers is used to being able to do certain things. There are similar needs and attitudes among other groups as well; for example, if TurboGears had its own IDE, and it couldn't easily be manipulated from the command line or its files edited in a plain-text editor, Linux devs probably wouldn't give it a second look, but most Windows devs would probably see it as only a minor drawback. I think the reasons are mostly historical--Windows has a stronger tradition of full-featured IDEs (starting with Borland's "Turbo" series) than UNIX does, probably because Windows has a stronger tradition of graphical *whatever* than UNIX does. > > my personal approach when something goes really wrong is that I try to > > reproduce it on a python console > > Good way, but anyway at the moment I am interested in using debugger > for learning TurboGears, not that much for debugging ;) Working interactively with your code in a console is very common in the Python culture. That's probably one of the reasons there aren't too many people crying out for a great Python source debugger--it's easy to play with interactively, try new things on the fly, etc., and most Python apps are written in a way that makes sure that's possible. SQLObject is a bit of a pain in this regard, though. -- Tim Lesher <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
