Simon Willison's Weblog: debugging

TIL: Exception.add_note

2025-07-27T23:07:21+00:00

Neat tip from Danny Roy Greenfeld: Python 3.11 added a .add_note(message: str) method to the BaseException class, which means you can add one or more extra notes to any Python exception and they'll be displayed in the stacktrace!

Here's PEP 678 – Enriching Exceptions with Notes by Zac Hatfield-Dodds proposing the new feature back in 2021.

Via Lobste.rs

Tags: debugging, python

snoop

2024-01-31T18:19:29+00:00

snoop

Neat Python debugging utility by Alex Hall: snoop lets you “import snoop” and then add “@snoop” as a decorator to any function, which causes that function’s source code to be output directly to the console with details of any variable state changes that occur while it’s running.

I didn’t know you could make a Python module callable like that—turns out it’s running “sys.modules[’snoop’] = snoop” in the __init__.py module!

Tags: debugging, python

Finding and reporting an asyncio bug in Python 3.10

2021-10-09T04:46:30+00:00

I found a bug in Python 3.10 today! Some notes on how I found it and my process for handling it once I figured out what was going on.

Testing Datasette against Python 3.10

I finally got around to attempting to upgrade Datasette to the just-released Python 3.10 this morning. I started by adding "3.10" to the matrix of Python versions that Datasette is tested against by GitHub Actions:

strategy:
  matrix:
    python-version: ["3.6", "3.7", "3.8", "3.9", "3.10"]

That line previously looked like this:

python-version: [3.6, 3.7, 3.8, 3.9]

I switched to using quoted strings here based on a tip from Jeff Triplett, who pointed out that 3.10 is actually a floating point number in YAML syntax which will be treated as referring to Python 3.1 instead!

This one-line change in a pull request was all it took to run the tests against the new version of Python... and they failed, spectacularly.

Annoyingly the root error wasn't displayed directly in the tests, because it was triggered and then caught by Datasette's own error handling and turned into a 500 HTTP error. So, I needed to run Python 3.10 locally and it the debugger.

Running Python 3.10 locally

I occasionally use pyenv to manage multiple Python versions on my machine. I have this installed through Homebrew.

I had to run brew upgrade pyenv first, because my installed version didn't know about Python 3.10. Then I ran this:

pyenv install 3.10.0

Which gave me a Python 3.10 installation on my Mac in ~/.pyenv/versions/3.10.0/bin/python.

Finally, I created a new virtual environment using this version of Python.

~/.pyenv/versions/3.10.0/bin/python \
  -m venv /tmp/py310
# Now activate that virtual environment:
source /tmp/py310/bin/activate

I put this in my /tmp directory so I don't have to remember to clean it up later.

Having done this, I installed my Datasette test dependencies into the new environment and used pytest to run my tests:

% cd ~/Dropbox/Development/datasette
% pip install -e '.[test]'

Running pytest -x --pdb stopped at the first failing test and dropped me into a debugger where I could finally access the full traceback, which looked something like this:

  File "datasette/datasette/views/base.py", line 122, in dispatch_request
    await self.ds.refresh_schemas()
  File "datasette/datasette/app.py", line 344, in refresh_schemas
    await self._refresh_schemas()
  File "datasette/datasette/app.py", line 349, in _refresh_schemas
    await init_internal_db(internal_db)
  File "datasette/datasette/utils/internal_db.py", line 5, in init_internal_db
    await db.execute_write(
  File "datasette/datasette/database.py", line 102, in execute_write
    return await self.execute_write_fn(_inner, block=block)
  File "datasette/datasette/database.py", line 113, in execute_write_fn
    reply_queue = janus.Queue()
  File "janus/__init__.py", line 39, in __init__
    self._async_not_empty = asyncio.Condition(self._async_mutex)
  File "lib/python3.10/asyncio/locks.py", line 234, in __init__
    raise ValueError("loop argument must agree with lock")
ValueError: loop argument must agree with lock

So, something is going long with asyncio.Condition(), which is being called by janus.Queue().

Some background on Janus

The Janus library referenced here describes itself as a "Thread-safe asyncio-aware queue for Python".

I use it in Datasette for the write queue - a mechanism where writes can be safely made to a SQLite database by first queueing them up in memory.

Janus provides a mechanism that lets asyncio event tasks send and receive messages to Python threads, and vice-versa, via a queue class that is modelled on Python's own standard library queues. It's really neat.

Tracking the investigation in issue comments

Any time I'm investigating a bug I make sure that there's an associated GitHub issue or pull request, to give me somewhere to build up detailed notes of my investigation.

I used my PR #1481 for this. Now that I had an error message - "loop argument must agree with lock" - I did some initial Google searches and found to my surprise that it had very few existing mentions - my first clue that this might be related to the new Python 3.10 release itself.

I tracked down the relevant source code in both Python and the Janus library based on the traceback and linked to them from the issue comments. I pasted in copies of the relevant code too, since GitHub only magically embeds code from the same repository, not code from other repositories. You can see those comments here.

I always like to include copies of the code most likely to be the cause of a bug in an issue comment, to save myself from having to dig around for it again later on and to act as a historical record once the bug has been fixed.

I also started an issue in the Janus repo, with the title Error with Python 3.10: "ValueError: loop argument must agree with lock". I linked this to my own issue and posted relevant research in both places.

The two lines of code in Janus that caused the bug where these ones (note my added comment):

self._async_mutex = asyncio.Lock()
# "loop argument must agree with lock" exception is raised here:
self._async_not_empty = asyncio.Condition(self._async_mutex)

This is where I began to suspect a Python bug. The above code can be simplified to this:

asyncio.Condition(asyncio.Lock())

This is a documented way of using conditions in Python: you can instantiate conditions with an optional lock, which allows that lock to be shared by more than one condition.

So I tried that in the Python 3.10 interpreter... and it didn't throw the error:

% ~/.pyenv/versions/3.10.0/bin/python
Python 3.10.0 (default, Oct  7 2021, 13:45:58) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> print(asyncio.Condition(asyncio.Lock()))
<asyncio.locks.Condition object at 0x1062521d0 [unlocked]>

From browsing the source code I could see that there was something going on here involving the event loop - so on a hunch I tried running that code in an event loop instead, like so:

>>> async def example():
...     print(asyncio.Condition(asyncio.Lock()))
... 
>>> asyncio.run(example())
Traceback (most recent call last):
  ...
  File "<stdin>", line 2, in example
  File "/Users/simon/.pyenv/versions/3.10.0/lib/python3.10/asyncio/locks.py", line 234, in __init__
    raise ValueError("loop argument must agree with lock")
ValueError: loop argument must agree with lock

There's the exception!

So it looked like this might be a genuine Python 3.10 bug. After all, I knew that this code worked in prior versions of Python (since Janus and Datasette worked fine there). In fact I could confirm it like so:

~ % python3.9
Python 3.9.7 (default, Sep  3 2021, 12:45:31) 
[Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> async def example():
...     print(asyncio.Condition(asyncio.Lock()))
... 
>>> asyncio.run(example())
<asyncio.locks.Condition object at 0x1049aab50 [unlocked]>

Reporting the bug to the Python issue tracker

Python bugs are tracked on bugs.python.org - thankfully they support sign in with GitHub (and Google and even OpenID) so I signed in with my GitHub account to report the bug.

I filed Issue 45416 entitled:

"loop argument must agree with lock" instantiating asyncio.Condition

And included a brief description with my minimal Python script that demonstrated the bug.

Then I added a comment pointing back to one of the related GitHub issues where I had been figuring this out, and another comment that linked to the most relevant test in Python's own test suite, which I found using GitHub search for the term Condition.

Any time I file an issue against a project - my own or someone else's - I always like to do a bit of extra research and link to both the likely code at fault and the likely test.

As a maintainer, this saves me a bunch of time - if the issue links straight to the code and tests I don't have to spend any time digging around looking for them.

My hope is that this saves time for the people I am reporting the bug to as well, which increases the chance that they'll dig into it and help me find a fix!

Then I tweeted about it. I have a bunch of followers with relevant experience, so I thought it was time to get a few more eyes on the problem.

I think I /may/ have found a bug in Python 3.10, which is exciting!

asyncio.Condition(asyncio.Lock()) raises a ValueError error if executed while an event loop is running

Means Datasette doesn't work on 3.10 (yet)https://t.co/ofd9MmzuJS pic.twitter.com/ICQz8lf39M
- Simon Willison (@simonw) October 8, 2021

I included a screenshot of my steps-to-reproduce script to save anyone who might be casually interested from having to click through to the issue itself.

Łukasz Langa to the rescue

Łukasz is the "CPython Developer in Residence", which means he is paid by the Python Software Foundation to work on Python full-time.

Less than an hour after I filed the issue he posted a comment that both confirmed the bug and provided two short-term workarounds for it!

I really liked his first workaround, which looks like this:

>>> l = asyncio.Lock()
>>> getattr(l, '_get_loop', lambda: None)()
<_UnixSelectorEventLoop running=True closed=False debug=False>

It works by calling the lock._get_loop() method, but only if it exists - so even though that's an undocumented internal method this should be safe even when run against future Python versions that might remove the method.

You can see that method here - it safely populates the self._loop property, which helps work around the bug.

Submitting a PR to Janus

The best place to apply this workaround is to Janus - so I submitted a PR there which adds the workaround and updates their CI configuration to test against Python 3.10: Janus PR #359. The GitHub Actions tests for that PR are now passing against Python 3.10.

Their README links to a gitter chat so I dropped a link to my PR in there too. Hopefully that can be merged soon!

What I should have done

I'm feeling pretty good about this situation - the bug is set to be fixed, we have a great workaround thanks to Łukasz and I'm optimistic that the upstream library from Datasette will land the fix soon.

If only I'd done this a few weeks earlier!

The Python 3.10 release schedule shipped the first alpha a year ago, in October 2020. It totalled 7 alphas, 4 betas and 2 release candidates before the final 3.10 release on Monday 4th October 2021.

If I'd taken the time to get Datasette's test suite running against Python 3.10 for any of those pre-releases, I could have helped spot this bug before it landed in the final release!

So lesson learned: Python has alphas and betas and RCs for a reason. For future Pythons I'm going to pay attention to testing against these for my projects before the final release lands.

Tags: async, debugging, python, weeknotes, github-actions

github-debug.com

2018-10-10T19:32:35+00:00

github-debug.com

This is a neat trick: GitHub have a dedicated site for their support engineers to send you to if you can’t connect to them. The site tests download speeds from their various domains and then lets you click a button to have GitHub run a traceroute/ping from their servers to your detected IP address and output the results (use devtools to spy on their API method for doing this). Then you can paste the results into a message to their support team. Turns out fastly-debug.com and dropbox-debug.com implement a similar pattern for those services as well.

Via Dropbox traffic infrastructure: Edge network

Tags: debugging, github, support

Quoting @simonw

2018-02-03T05:23:36+00:00

Just switched to {window.localStorage.getItem('debug') && <pre>{JSON.stringify(this.state, null, 2)}</pre>} - now I can ship to production and turn on debugging in my console with localStorage.setItem('debug', 1)

— @simonw

Tags: debugging, react

Appending the request URL to SQL statements in Django

2010-06-02T09:09:00+00:00

Appending the request URL to SQL statements in Django

A clever frame-walking monkey-patch which pulls the most recent HttpRequest object out of the Python stack and adds the current request.path to each SQL query as an SQL comment, so you can see it in debugging tools such as slow query logs and the PostgreSQL “select * from pg_stat_activity” query.

Tags: chris-lamb, debugging, django, orm, postgresql, python, sql, recovered, monkeypatch

Fun with TextMate and PDB

2010-03-23T09:48:09+00:00

Fun with TextMate and PDB

TextMate bookmarks (against lines in a file) are stored as OS X extended attributes, which can be accessed from Python using the xattr module. Here’s a clever piece of code that uses bookmarks to set breakpoints in the command-line pdb debugger.

Tags: debugging, macos, pdb, python, textmate, xattr

Presenting django-devserver, a better runserver

2010-02-10T11:33:12+00:00

Presenting django-devserver, a better runserver

I really like this—it’s a Django management command (./manage.py rundevserver) which adds SQL logging and cache access summaries to the console output of Django’s local development server. It solves a similar set of problems to the debug toolbar, but requires slightly less setup and doesn’t inject additional HTML in to your pages. You can add your own custom modules to it as well.

Tags: david-cramer, debugging, devserver, django, python, runserver

Debugging in Python

2009-11-18T12:34:29+00:00

Debugging in Python

The missing manual for Python’s powerful pdb debugger.

Tags: debugger, debugging, pdb, python

Deep Tracing of Internet Explorer

2009-11-18T08:06:47+00:00

Deep Tracing of Internet Explorer

dynaTrace Ajax looks like an awesome tool. For once, Internet Explorer has a development tool that other browsers can be jealous of.

Tags: ajax, debugging, dynatraceajax, internet-explorer, javascript, john-resig

django-debug-toolbar

2009-09-21T18:36:53+00:00

django-debug-toolbar

The new panel styling for the Django debug toolbar is really slick—here’s a neatly produced screencast demonstrating it (with Gypsy Jazz accompaniment).

Tags: debugging, django, django-debug-toolbar, gypsyjazz, screencasts

Debugging Django in Production Revisited

2009-09-07T05:21:04+00:00

Debugging Django in Production Revisited

Eric Holscher expands his show-technical-errors-to-superusers middleware to only show them to users in the group named “Technical Errors”.

Tags: debugging, django, eric-holscher, middleware, python

Why I don't love JavaScript's Module Pattern

2009-04-30T19:59:39+00:00

Why I don't love JavaScript's Module Pattern

Jonathan Snook points out that the module pattern (where private functionality is hidden in a closure and only public methods are revealed to outside scopes) makes code a lot harder to debug. I use the module pattern for pretty much everything, not because I want to keep stuff private but more to avoid any chance of leaking out in to the global namespace. If I need to debug a value I temporarily assign it as a property on the global window object.

Tags: closures, debugging, javascript, jonathan-snook, modulepattern

Finding and fixing memory leaks in Python

2009-04-22T12:16:32+00:00

Finding and fixing memory leaks in Python

Using Dozer, a clever piece of WSGI middleware which displays sparklines of Python object counts and allows you to introspect them, using the gc module under the hood.

Tags: amir-salihefendic, debugging, memory, memoryleaks, middleware, python, wsgi

Announcing django-viewtools

2009-02-17T21:35:31+00:00

Announcing django-viewtools

A really excellent idea—run ./manage.py viewtools --pdb /path/on/site/ to debug a view in your Django project that is raising an error using the Python debugger, or use --profile to run the full request cycle for that URL through the profiler.

Tags: debugging, django, djangoviewtools, eric-moritz, pdb, profiler, python

ReferenceError: console is not defined

2008-12-23T22:22:39+00:00

ReferenceError: console is not defined

Since Firebug 1.2 you need to call window.loadFirebugConsole() in order for console.log and friends to work.

Tags: debugging, firebug, firefox, javascript

Introducing the Django Debug Toolbar

2008-09-21T18:32:24+00:00

Introducing the Django Debug Toolbar

Another project inspired by DjangoCon: a component based debugging toolbar for Django. I like the architecture so far.

Tags: debugging, django, djangocon, django-debug-toolbar, rob-hudson

Django snippets: server with debugging backdoor

2008-09-08T22:15:45+00:00

Django snippets: server with debugging backdoor

Six lines of code that uses spawning to fire up a Django server on port 8000 and a remote interactive interpreter backdoor on port 8001, so you can interogate the state of your server within the same process.

Tags: debugging, django, python, spawning

Super User Conditional Page Exception Reporting

2008-07-31T21:06:30+00:00

Super User Conditional Page Exception Reporting

The name is almost as long as the code snippet: this serves Django’s debug page to logged in super-users, falling back to the default 500 template for everyone else.

Tags: debugging, django, exceptions, middleware, python

Firebug Lite 1.2

2008-07-27T09:30:14+00:00

Firebug Lite 1.2

Huge upgrade to the IE/Opera/Safari bookmarklet version of Firebug—it now has DOM element inspection, XHR tracking and an interactive console, among other features.

Via Steve Souders

Tags: bookmarklets, debugging, firebug, firebuglite, javascript

Debugging Django, a slidecast

2008-05-25T14:47:02+00:00

Debugging Django, a slidecast

I used SlideShare’s slidecast tool for the first time to synchronize audio of my Django London User Group talk with the slides. The talk included several live demos which aren’t represented in the slides so it’s a bit piecemeal in places.

Tags: debugging, django, djugl, slidecast, slideshare, speaking, my-talks

modswgi: Debugging Techniques

2008-05-25T13:34:42+00:00

modswgi: Debugging Techniques

mod_wsgi is excellent software, and the documentation is equally superb. I used these instructions recently to run the Python debugger inside a running instance of Apache, which helped my track down some import errors that weren’t occurring with Django’s development server.

Tags: debugging, django, modwsgi, pdb, python, wsgi

Debugging Django

2008-05-22T00:35:40+00:00

I gave a talk on Debugging Django applications at Monday's inaugural meeting of DJUGL, the London Django Users Group. I wanted to talk about something that wasn't particularly well documented elsewhere, so I pitched the talk as "Bug Driven Development" - what happens when Test Driven Development goes the way of this unfortunate pony.

The slides are up on SlideShare, but don't provide quite enough context so I'm going to cover the tips in full here.

Making the most of the error page

Django's default error page is great - it provides a detailed traceback with local variables, lets you expand out the lines of code around the problem, provides a plain text exception suitable for e-mailing to colleagues and even a one-click button to send details to http://dpaste.com/ so you can go and talk about the error on IRC. It also serves the same purpose as phpinfo() - it shows you your application's settings, the GET, POST and COOKIE data from the request and the all important META fields assembled from the HTTP environment (great for remembering how to miss-spell HTTP_REFERER).

Useful tip number one is that you can trigger the error page from any view just by adding the following line:

assert False

You can serve up an expression with the assertion as well; it will be displayed at the top of the error page:

assert False, request.GET

One particularly useful place to use this is when you are building a complex form. If you want to see the data that was submitted, drop an assert False in to the view that the form targets and use the error page to inspect the data.

Logging to the development server console

If you want to know what's going on inside a view, the quickest way is to drop in a print statement. The development server outputs any print statements directly to the terminal; it's the server-side alternative to a JavaScript alert().

If you want to be a bit more sophisticated with your logging, it's worth turning to Python's logging module (part of the standard library). You can configure it in your settings.py:

import logging
logging.basicConfig(
    level = logging.DEBUG,
    format = '%(asctime)s %(levelname)s %(message)s',
)

Then call it from any of your views:

def my_view(request):
    import logging
    logging.debug("A log message")
    ...

Again, this will log things to the terminal where the development server is running. If you want to log things to a file you can do so by extending the basicConfig call:

logging.basicConfig(
    level = logging.DEBUG,
    format = '%(asctime)s %(levelname)s %(message)s',
    filename = '/tmp/myapp.log',
    filemode = 'w'
)

You can then use tail -f /tmp/myapp.log to see log lines being appended to that file in real-time. This can be used in production as well as development.

The above just scratches the surface of Python's logging module; with a bit of digging around in the documentation you can use it to rotate log files, send log messages over the network and even POST log events to an HTTP server somewhere.

Often you find yourself dealing with an error that only occurs in certain circumstances - a function might be called from dozens of different places in your program but only runs in to trouble in a very specific case. You can use the traceback module to log the current stack, which will allow you to tell how a function was called when something went wrong:

import logging, traceback, pprint

def my_buggy_function(arg):
    ...
    if error_condition:
        stack = pprint.pformat(traceback.extract_stack())
        logging.debug('An error occurred: %s' % stack)

The tuple returned by traceback.extract_stack() includes line numbers, function names and paths to Python files so you can use it to reconstruct a good amount of information about your program.

Using the debugger

By far the most powerful weapon in my debugging toolkit is the Python debugger, pdb. Again, this ships with the standard library so there's nothing extra to install. pdb is a command line debugger (if you want a GUI options include PyEclipse and Komodo, but I haven't used either myself). There are a bunch of ways to activate pdb, but the most straight forward is to simply drop the following line directly in to a Django view function:

import pdb; pdb.set_trace()

If you try to load that page in your browser, the browser will hang - the page will appear to be loading extremely slowly. What's actually happened is the developer server has paused execution and thrown up the pdb interface - you can switch over to your console and start interacting directly with the server mid view.

Did I mention you should never, ever leave this on in production?

So, you've got a hung development server and a pdb prompt. What can you do with it? The answer is pretty much anything. I won't provide a full pdb tutorial here (this is a good introduction), but the commands I find most useful are the following:

list: Shows the lines of source code around your current point of execution. You can run it multiple times to increase the amount of source code displayed.
n: Execute the next line
s: Same as n, but steps in to any functions that are called. You can quickly get lost in a twisty maze of code with this command, but that's OK because...
r: Continues execution until the current function returns
u: Goes UP one level in the stack - so you can see the function that called the function you are currently in
d: Goes DOWN again
locals(): not a pdb command, but handy for seeing what's in your current scope

The pdb docs have a full list of commands.

The pdb prompt doubles up as a full Python interactive shell, so you can not only access variables but you can modify them, call functions and generally mess around with the internals of your application as much as you like, while it's running. It's kind of a poor man's imitation of being a Smalltalk developer.

Remember though, the whole time you're messing around in pdb your browser is still stuck there, waiting for the HTTP request to come back. If you hit "c" (for continue) your application will kick in again, the request will be served and your browser will breathe a sigh of relief.

Thankfully you don't have to use pdb in a way that freezes your development server; it also works great in the interactive shell. If you've got a buggy function, one way to explore it is to run it interactively, then use the following idiom:

>>> def function_that_raises_an_exception():
...   assert False
... 
>>> function_that_raises_an_exception()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in function_that_raises_an_exception
AssertionError
>>> import pdb; pdb.pm()
> <stdin>(2)function_that_raises_an_exception()
(Pdb)

pdb.pm() stands for post-mortem, and is probably my favourite feature of the debugger - it lets you jump back in to debug the most recently raised exception, even if you hadn't imported pdb at the time the exception was raised.

One last pdb tip: you can use it to debug Python command line scripts such as Django's custom ./manage.py commands. The trick is to run the script like this:

python -i manage.py buggy_command

The -i argument causes Python to drop in to the interactive prompt after executing the script. If the script raised an exception, you can then use pdb.pm() to debug it.

Handling errors in production

Django's default behaviour in production (that is, when the DEBUG setting is set to False) is to e-mail exception reports to anyone listed in the ADMINS section. You can also turn on e-mail reports on every 404 error with the SEND_BROKEN_LINK_EMAILS setting, which will send them to addresses in the MANAGERS setting. As far as I know these settings don't do anything else - they're a pretty ancient bit of Django.

On a high traffic site you probably don't want to be e-mailed on every server error. One neat alternative is David Cramer's django-db-log, which logs exceptions to a database table. It cleverly uses an MD5 hash of the traceback to aggregate many reports of the same error. More importantly though, it acts as a really straight forward example of how to use Django middleware's process_exception hook to roll your own error reporting. Take a look at the code to see how simple this is.

More useful middleware

In the talk I demoed a couple of other handy pieces of middleware. The first was the ProfilerMiddleware (one of several profiling tools on Django Snippets) which allows you to add ?prof to the end of any URL to see the output of Python's cProfile module run against that request. The second is one that I've just released: DebugFooter, which adds a footer showing exactly which templates were loaded from where (handy for debugging complex template paths) as well as every executed SQL query and how long each one took.

Abusing the test client

A final tip for exploring your application interactively is to learn to use Django's TestClient. Although designed for use in unit tests, this tool is equally useful for use at the interactive prompt. It allows you to simulate an in-process request against your application from within your Python code. Here's an example:

>>> from django.test.client import Client
>>> c = Client()
>>> response = c.get("/") # The homepage
>>> response
<django.http.HttpResponse object at 0x2300470>
>>> print response
Vary: Cookie
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
...

The response object you get back is the HttpResponse returned by the view, ready to be explored interactively.

There's another function from the unit testing tools that can help with interactively exploring an application: setup_test_environment(). This function monkey-patches in some additional hooks used by the unit tests, including one that intercepts template render calls and adds information on them to the request object. Here's an example:

>>> from django.test.utils import setup_test_environment
>>> setup_test_environment()
>>> from django.test.client import Client
>>> c = Client()
>>> response = c.get("/")
>>> response.template
[<django.template.Template object at 0x2723dd0>,
 <django.template.Template object at 0x2723f30>,
 <django.template.Template object at 0x273ee10>]
>>> response.context
[ list of Context objects ]

This allows you to explore not just the HTML returned by a view, but also the templates and contexts that were used to render it.

Your tips welcome

If you have any useful tips on debugging Django applications, please share them in the comments on this entry.

Tags: debugging, django, djugl, middleware, my-talks, testing

Firebug Command Line API

2008-05-16T12:14:34+00:00

Firebug Command Line API

Another thing I didn’t know about Firebug: you can set a breakpoint at the start of a function with “debug(fn)” and log all calls to it with “monitor(fn)”.

Tags: debugging, firebug, javascript

Opera Dragonfly

2008-05-06T19:04:41+00:00

Opera Dragonfly

Opera’s new Firebug-style developer console. Out in alpha and it shows (slow to load and the interactive console leaves a lot to be desired) but still looks incredibly promising, especially the remote debugging tools for working with Opera on phones and games consoles.

Tags: debugging, dragonfly, firebug, opera

Advanced JavaScript Debugging Techniques

2008-04-04T07:51:05+00:00

Advanced JavaScript Debugging Techniques

There’s more to JavaScript debugging than just Firebug.

Tags: debugging, firebug, javascript, sitepen

Firebug + Dijit tips

2008-03-17T02:08:23+00:00

Firebug + Dijit tips

News to me: Firebug has a magic $1 variable which corresponds to the currently selected node. Very handy.

Tags: debugging, dijit, dojo, firebug, javascript

Quoting Jon Hicks

2007-12-20T15:09:02+00:00

I don't even use Firefox and Firebug anymore, the revised Web Inspector in Leopard has been incorporated in Coda and that does everything I need and more.

— Jon Hicks

Tags: coda, css, debugging, firebug, firefox, html, jon-hicks, leopard, software, webinspector

DebugBar

2007-11-25T10:32:14+00:00

DebugBar

Suggested at BarCamp London 3 as a useful tool for developing with IE; apparently includes a great JavaScript debugger.

Tags: barcamplondon3, debugbar, debugger, debugging, internet-explorer, javascript

jQuery Logging

2007-10-19T12:52:50+00:00

jQuery Logging

Brilliant four line jQuery plugin that lets you insert Firebug console.log() calls directly in to chains.

Via Jabbering Giraffe

Tags: debugging, dominic-mitchell, firebug, javascript, jquery, logging