Pdb;pdb.set_trace() alternative

Quick question.
Currently when I'm debugging in Plone I tend to use:

 import pdb;pdb.set_trace()

Is anyone using something different/better?

3 Likes

I'm using Products.PDBDebugMode, I can't develop without it. You enter a pdb automatically when there is an exception.

Hello,
I also use that, but I prefere using

import ipdb; ipdb.set_trace()

And I also use 2 packages, It depends on what I have to debug :

  1. iw.debug : With this package, I can append /ipdb after any url. Then you arrive in ipdb shell and context is url (example : /plone/path/to/my/object/to/debug/ipdb, debug object is context in your terminal)
  2. Products.PDBDebugMode : With this package you arrive in pdb shell when an exeption is raised by Zope/Plone.
1 Like

With Products.PDBDebugMode, you have a view /@@pdb that you can call on any context too.

3 Likes

@bsuttor and @vincentfretin very useful. I've come across PDBDebugMode before but these additional tips should make my life even easier.

You can also easily debug templates, when you using Chameleon (five.pt) as TAL engine:

Just include:

< tal:something >

<?python import ipdb; ipdb.set_trace() ?>

< /tal:something >

In console you just write ipdb> pp econtext to get the current local variables. (Note: In some template bindings it's rcontext.) Other than that, I can suggest to exploit the new commands of ipdb such as pinfo to display information about an object (docstring, signature, path to source, etc.).

5 Likes

A refinement for this trick!

<?python locals().update(econtext); import ipdb; ipdb.set_trace() ?>

Which loads in the locals the variables defined in the template (econtext)!

9 Likes

Note that the Chameleon trick only works in Zope 3 templates, so not in skin templates and not in TTW templates.

If you find that you can use it in those, then you should install the April 2016 hotfix. :slight_smile: See https://plone.org/security/hotfix/20160419/bypass-restricted-python

3 Likes

I'm glad I asked @pgg, @alert and @mauritsvanrees. Lots of useful information here :).

Besides the solutions already discussed, I also heavily use interactive debugging via "bin/{client1|instance} debug". It gives you an interactive Python interpreter with access to Zope's root object (bound to "app"). In the interpreter, you can do "normal" Python debugging.

I do use bin/instance debug, mostly when I'm developing custom scripts.

I've been using pdb++ for a while now and really like it. The best feature is the command ll which is like l but always shows the current menthod in full. I'll also give a talk on debugging at the upcoming conference where I'll show some more nice tricks :smiley:
@alert: nice trick updating the locals. I'll add that to https://www.starzel.de/blog/magic-templates-in-plone-5

4 Likes

Great! That post is awesome :slight_smile:

Every newbie should bookmark this thread under the heading "Plone debugging" :slight_smile:

1 Like

Or you could update the manual?

@djay ... Very true sir.

And let's not forget the excellent Plone Reloader Chrome extension, for when you want to quickly make some changes to a python file (such as adding/removing pdb) and avoid restarting Zope. Beats going to http://localhost:8080/@@reload, plus has some Diazo debugging goodies:

2 Likes

Indeed @djay. It would be a nice addition to https://docs.plone.org/develop/debugging/pdb.html

I look forward to seeing the documentation pull request! :wink:

The contributor's problem again, rs. We already have your e-mail but we still need to address some stuff with the legal department before being able to do PRs to /plone, at least we're already doing it to /collective.