How to debug in Django, the good way? [closed]

Question

So, I started learning to code in Python and later Django. The first times it was hard looking at tracebacks and actually figure out what I did wrong and where the syntax error was. Some time has passed now and some way along the way, I guess I got a routine in debugging my Django code. As this was done early in my coding experience, I sat down and wondered if how I was doing this was ineffective and could be done faster. I usually manage to find and correct the bugs in my code, but I wonder if I should be doing it faster?

I usually just use the debug info Django gives when enabled. When things do end up as I thought it would, I break the code flow a lot with a syntax error, and look at the variables at that point in the flow to figure out, where the code does something other than what I wanted.

But can this be improved? Are there some good tools or better ways to debug your Django code?

Loxodromic

i like to use django-debug-toolbar, its very handfull – Insurance

Or use Visual Studio Code's built in Python debugger as explained here code.visualstudio.com/docs/python/tutorial-django – Lizzielizzy

You can do this with PyCharm with either runserver or shell. See this answer. – Paraphrast

Answer 1

There are a bunch of ways to do it, but the most straightforward is to simply use the Python debugger. Just add following line in to a Django view function:

import pdb; pdb.set_trace()

or

breakpoint()  #from Python3.7

If you try to load that page in your browser, the browser will hang and you get a prompt to carry on debugging on actual executing code.

However there are other options (I am not recommending them):

* return HttpResponse({variable to inspect})

* print {variable to inspect}

* raise Exception({variable to inspect})

But the Python Debugger (pdb) is highly recommended for all types of Python code. If you are already into pdb, you'd also want to have a look at IPDB that uses ipython for debugging.

Some more useful extension to pdb are

pdb++, suggested by Antash.

pudb, suggested by PatDuJour.

Using the Python debugger in Django, suggested by Seafangs.

Eliseelisee

+1 for suggesting pdb. However it's worth noting that this only really works when using the development server on your local machine, as the prompt will appear in the console. – Overgrowth

See also django-pdb as per my answer below. Gives you manage.py runserver --pdb and manage.py test --pdb commands. – Stratum

@Daniel, see rconsole for having a console into an already running instance of python. – Sarraute

Check out ipython as well. Ipdb, which comes with ipython, features tab completion, colored syntax, and more :-). – Firebug

I found your answer useful but Django was hanging forever on my breakpoints, when I was trying to debug a test. So I looked and found an informative article that helped me out: v3.mike.tig.as/blog/2010/09/14/pdb – Premillennial

raise Exception('garbage') actually works fantastically well when coupled with the Werkzeug debugger, considering that in most cases you simply want to know what locals exist at some scope. – Emphasize

If you plan using pdb, check out pudb. It uses ncurses to provide a very nice UI while debugging the code. Just use import pudb; pu.db. – Aeolipile

@hangtwenty your link no longer works. Here's a live cheatsheet of commands for the pdb degugger – Angieangil

Another tool similar to rconsole: remote-pdb. Either could be activated by a signal, such as USR1. – Airspeed

pdb is fantastic, and I use it all the time, but there is always the danger of inadvertently committing a set_trace, and of that commit getting onto master, which would be a problem. If you're using pdb, it's a very good idea to add a pre-commit hook blocking commits which contain that import. – Dishabille

Yup, i used today. Debugging each line of code. But it still quite hard. Since we have to create marker and save it whenever we need to evaluate python results. Perhaps there is another way to debug django soon. – Terminology

check out pudb, a robust in shell debugging tool created by Professor Matloff from UC Davis. It traces variables, stacks, and other key information on top of what pdb can do. – Miscellanea

It's also worth to check pdbpp which is a drop-in replacement for pdb, meaning that it overrides the later one, thus it's really nice to use with pytest --pdb and it's IMHO better than ipdb. – Erudite

@Jon Kiparsky >> commiting set_trace : I use alias nodebug='git diff|grep alert ; git diff|grep console.log ; git diff|grep debugger ; git diff|grep alert ; git diff|grep set_trace ; git diff|grep localhost' and run this before the commit – Aggrade

Since Django 3 it's not necessary to install a library to run manage.py test --pdb – Pneumatology

Raising exceptions may not be the most elegant way to debug, but boy it works perfectly. Done is better than perfect. Thumbs up! – Germanophile

Answer 2

I really like Werkzeug's interactive debugger. It's similar to Django's debug page, except that you get an interactive shell on every level of the traceback. If you use the django-extensions, you get a runserver_plus managment command which starts the development server and gives you Werkzeug's debugger on exceptions.

Of course, you should only run this locally, as it gives anyone with a browser the rights to execute arbitrary python code in the context of the server.

Birth

Is it possible to use tab completion in the interactive console shown in the browser? "Tab" just takes us to the next open console, I was wondering if there was a key combination, but I couldn't find one. – Drainpipe

@Drainpipe the werkzeug debugger does not have tab completion. – Reganregard

If you are debbugging APIs, you could try django-rundbg that adds a little twist to the Werkzeug debugger. – Flue

It is only up to python 3.3 – Trojan

doesn't support channels github.com/pallets/werkzeug/issues/1322 – Falter

Answer 3

A little quickie for template tags:

@register.filter 
def pdb(element):
    import pdb; pdb.set_trace()
    return element

Now, inside a template you can do {{ template_var|pdb }} and enter a pdb session (given you're running the local devel server) where you can inspect element to your heart's content.

It's a very nice way to see what's happened to your object when it arrives at the template.

Exhaust

this is great. Another thing you can do if you're having template problems is to switch to jinja2 (loaded through coffin) - it's an extension of django templates, which is an improvement in my opinion. It also integrates templates & template inheritance into traceback frames way better than django does. – Seven

This is lovely. Unfortunately, it's hard to see a clean way to integrate this into a codebase which refuses any commit including an import of pdb. – Dishabille

Answer 4

There are a few tools that cooperate well and can make your debugging task easier.

Most important is the Django debug toolbar.

Then you need good logging using the Python logging facility. You can send logging output to a log file, but an easier option is sending log output to firepython. To use this you need to use the Firefox browser with the firebug extension. Firepython includes a firebug plugin that will display any server-side logging in a Firebug tab.

Firebug itself is also critical for debugging the Javascript side of any app you develop. (Assuming you have some JS code of course).

I also liked django-viewtools for debugging views interactively using pdb, but I don't use it that much.

There are more useful tools like dozer for tracking down memory leaks (there are also other good suggestions given in answers here on SO for memory tracking).

Willyt

Answer 5

I use PyCharm (same pydev engine as eclipse). Really helps me to visually be able to step through my code and see what is happening.

Lovins

best thing about it is it just works and is totally intuitive. Just click to the left of a line and hit the debug button. It works well for Django source code too if you want to get a better understanding of how the internal code works. It took me a while before I noticed it, but you can put breakpoints in any of the code in External Libraries folder of the file navigator. – Herringbone

Worth to mention that PyCharm uses PyDev debugger under the hood for credits. – Faye

https://mcmap.net/q/64963/-how-to-run-debug-server-for-django-project-in-pycharm-community-edition – Ginzburg

Except that it's broken! Most recent stable version won't halt on a breakpoint after initialization; total POS. – Addis

PyCharm or (django-)pdb is really fine. The main point is to find the usable mapping and breakpoint. I wanted to debug a docker-based Django at a local curl call, like "curl localhost:8080/api...." – and it was not trivial to catch this call. But finally succeeded. Tricky point is, that it's useful to put a breakpoint NOT into the application code, but into the django core code, like wsgi.py or rest_framework/viewsets.py. For this a good mapping is needed, but in PyCharm Professional it is semi-automatic. Finally you can see serializers, queries, anything. porgeto.hu/Py.png – Joinery

Useful breakpoints to catch a curl call: wsgiref/simple_server.py:get_app, 64: F9 to continue rest_framework/views.py:view, 94: F9 to continue rest_framework/views.py:dispatch, 502: F7 to step in rest_framework/mixins.py:list, queryset = ... F8 to explore – Joinery

I know about PyCharm but how do I actually use it to debug my Django project. Just saying to use it is not very helpful. – Paraphrast

Answer 6

Almost everything has been mentioned so far, so I'll only add that instead of pdb.set_trace() one can use ipdb.set_trace() which uses iPython and therefore is more powerful (autocomplete and other goodies). This requires ipdb package, so you only need to pip install ipdb

Triangulation

I recommend pdb++ which provides a very useful sticky mode. – Copro

Answer 7

I've pushed django-pdb to PyPI. It's a simple app that means you don't need to edit your source code every time you want to break into pdb.

Installation is just...

1. pip install django-pdb
2. Add 'django_pdb' to your INSTALLED_APPS

You can now run: manage.py runserver --pdb to break into pdb at the start of every view...

bash: manage.py runserver --pdb
Validating models...

0 errors found
Django version 1.3, using settings 'testproject.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

GET /
function "myview" in testapp/views.py:6
args: ()
kwargs: {}

> /Users/tom/github/django-pdb/testproject/testapp/views.py(7)myview()
-> a = 1
(Pdb)

And run: manage.py test --pdb to break into pdb on test failures/errors...

bash: manage.py test testapp --pdb
Creating test database for alias 'default'...
E
======================================================================
>>> test_error (testapp.tests.SimpleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".../django-pdb/testproject/testapp/tests.py", line 16, in test_error
    one_plus_one = four
NameError: global name 'four' is not defined
======================================================================

> /Users/tom/github/django-pdb/testproject/testapp/tests.py(16)test_error()
-> one_plus_one = four
(Pdb)

The project's hosted on GitHub, contributions are welcome of course.

Stratum

This would be great if you could specify the file / line number to break at (not just the view). – Sallyanne

To which I could leave in the code like comments of which are inert within production. Perhaps this is a bad paradim, but it would be great to effectively strip and apply breaks willy-nilly. – Nutgall

I installed this recently, but only today figured out to configure "POST_MORTEM=True" in my dev settings as documented by Tom's django-pdb. Now I can just cruise along and when things go bad I'm dropped right to the location of the problem. Thanks Tom! – Carburize

manage.py runserver: error: unrecognized arguments: --pdb – Whirlpool

Answer 8

The easiest way to debug python - especially for programmers that are used to Visual Studio - is using PTVS (Python Tools for Visual Studio). The steps are simple:

1. Download and install it from https://microsoft.github.io/PTVS/
2. Set breakpoints and press F5.
3. Your breakpoint is hit, you can view/change the variables as easy as debugging C#/C++ programs.
4. That's all :)

If you want to debug Django using PTVS, you need to do the following:

1. In Project settings - General tab, set "Startup File" to "manage.py", the entry point of the Django program.
2. In Project settings - Debug tab, set "Script Arguments" to "runserver --noreload". The key point is the "--noreload" here. If you don't set it, your breakpoints won't be hit.
3. Enjoy it.

Scoreboard

Thanks, that worked great. The --noreload was what we needed – Soda

Is there a feature to debug on remote server - similar to Eclipse PyDev that I use at the moment? – Doriandoric

I am having problems with this. I followed your steps but still doesn't work. It only stops in the breakpoints of *.py files, not in the *.html ones. – Gravois

Answer 9

I use pyDev with Eclipse really good, set break points, step into code, view values on any objects and variables, try it.

Kala

You do have to run the dev server through eclipse (for the low-effort debugging experience). PyDev claims to have remote debugging but having never used it I can't really speak to the quality of development experience. Details: pydev.org/manual_adv_remote_debugger.html – Charlet

PyDev's remote debugger works quite wonderfully with Django's dev server. Just make sure you have the "When file is changed, automatically reload module?" option ''disabled'' in PyDev's Run/Debug settings. Otherwise the dev server and pydev will both try to reload the code while you're debugging, which gets them both extremely confused. – Saddlebag

Answer 10

I use PyCharm and stand by it all the way. It cost me a little but I have to say the advantage that I get out of it is priceless. I tried debugging from console and I do give people a lot of credit who can do that, but for me being able to visually debug my application(s) is great.

I have to say though, PyCharm does take a lot of memory. But then again, nothing good is free in life. They just came with their latest version 3. It also plays very well with Django, Flask and Google AppEngine. So, all in all, I'd say it's a great handy tool to have for any developer.

If you are not using it yet, I'd recommend to get the trial version for 30 days to take a look at the power of PyCharm. I'm sure there are other tools also available, such as Aptana. But I guess I just also like the way PyCharm looks. I feel very comfortable debugging my apps there.

Tamartamara

It could be the first IDE I ever buy. Debugging a project in a VM sounds like magic worth paying for. – Alton

I know about PyCharm but how do I actually use it to debug my Django project. Just saying to use it is not very helpful. – Paraphrast

Answer 11

From my perspective, we could break down common code debugging tasks into three distinct usage patterns:

1. Something has raised an exception: runserver_plus' Werkzeug debugger to the rescue. The ability to run custom code at all the trace levels is a killer. And if you're completely stuck, you can create a Gist to share with just a click.
2. Page is rendered, but the result is wrong: again, Werkzeug rocks. To make a breakpoint in code, just type assert False in the place you want to stop at.
3. Code works wrong, but the quick look doesn't help. Most probably, an algorithmic problem. Sigh. Then I usually fire up a console debugger PuDB: import pudb; pudb.set_trace(). The main advantage over [i]pdb is that PuDB (while looking as you're in 80's) makes setting custom watch expressions a breeze. And debugging a bunch of nested loops is much simpler with a GUI.

Ah, yes, the templates' woes. The most common (to me and my colleagues) problem is a wrong context: either you don't have a variable, or your variable doesn't have some attribute. If you're using debug toolbar, just inspect the context at the "Templates" section, or, if it's not sufficient, set a break in your views' code just after your context is filled up.

So it goes.

Zenger

type less using just import pudb;pu.db – Polanco

Answer 12

Add import pdb; pdb.set_trace() or breakpoint() (form python3.7) at the corresponding line in the Python code and execute it. The execution will stop with an interactive shell. In the shell you can execute Python code (i.e. print variables) or use commands such as:

• c continue execution
• n step to the next line within the same function
• s step to the next line in this function or a called function
• q quit the debugger/execution

Also see: https://poweruser.blog/setting-a-breakpoint-in-python-438e23fe6b28

Catarinacatarrh

Answer 13

Sometimes when I wan to explore around in a particular method and summoning pdb is just too cumbersome, I would add:

import IPython; IPython.embed()

IPython.embed() starts an IPython shell which have access to the local variables from the point where you call it.

Hello

I have made a habit now to do this at the top of the file from IPython import embed and then whenever I want to quickly add a breakpoint in the code, I write embed(). Saves time. To avoid getting stuck in loops forever, I do embed();exit(); – Dehnel

@MayankJaiswal: I had a key mapping on Vim to insert this snippet (and similar snippets for pudb and debugger; in JavaScript) into the file I'm editing. After I'm done, I just dd (delete entire line) to remove the breakpoint. This avoids the risk of committing the debugger import line into version control or having to preset the import first at the top of the file. – Hello

Answer 14

I just found wdb (http://www.rkblog.rk.edu.pl/w/p/debugging-python-code-browser-wdb-debugger/?goback=%2Egde_25827_member_255996401). It has a pretty nice user interface / GUI with all the bells and whistles. Author says this about wdb -

"There are IDEs like PyCharm that have their own debuggers. They offer similar or equal set of features ... However to use them you have to use those specific IDEs (and some of then are non-free or may not be available for all platforms). Pick the right tool for your needs."

Thought i'd just pass it on.

Also a very helpful article about python debuggers: https://zapier.com/engineering/debugging-python-boss/

Finally, if you'd like to see a nice graphical printout of your call stack in Django, checkout: https://github.com/joerick/pyinstrument. Just add pyinstrument.middleware.ProfilerMiddleware to MIDDLEWARE_CLASSES, then add ?profile to the end of the request URL to activate the profiler.

Can also run pyinstrument from command line or by importing as a module.

Unalloyed

PyCharm just uses PyDev I think, not its own one. – Alton

Answer 15

I highly recommend epdb (Extended Python Debugger).

https://bitbucket.org/dugan/epdb

One thing I love about epdb for debugging Django or other Python webservers is the epdb.serve() command. This sets a trace and serves this on a local port that you can connect to. Typical use case:

I have a view that I want to go through step-by-step. I'll insert the following at the point I want to set the trace.

import epdb; epdb.serve()

Once this code gets executed, I open a Python interpreter and connect to the serving instance. I can analyze all the values and step through the code using the standard pdb commands like n, s, etc.

In [2]: import epdb; epdb.connect()
(Epdb) request
<WSGIRequest
path:/foo,
GET:<QueryDict: {}>, 
POST:<QuestDict: {}>,
...
>
(Epdb) request.session.session_key
'i31kq7lljj3up5v7hbw9cff0rga2vlq5'
(Epdb) list
 85         raise some_error.CustomError()
 86 
 87     # Example login view
 88     def login(request, username, password):
 89         import epdb; epdb.serve()
 90  ->     return my_login_method(username, password)
 91
 92     # Example view to show session key
 93     def get_session_key(request):
 94         return request.session.session_key
 95

And tons more that you can learn about typing epdb help at any time.

If you want to serve or connect to multiple epdb instances at the same time, you can specify the port to listen on (default is 8080). I.e.

import epdb; epdb.serve(4242)

>> import epdb; epdb.connect(host='192.168.3.2', port=4242)

host defaults to 'localhost' if not specified. I threw it in here to demonstrate how you can use this to debug something other than a local instance, like a development server on your local LAN. Obviously, if you do this be careful that the set trace never makes it onto your production server!

As a quick note, you can still do the same thing as the accepted answer with epdb (import epdb; epdb.set_trace()) but I wanted to highlight the serve functionality since I've found it so useful.

Puckett

epdb is not updated since 2011. Do you ever run into problems using it on newer versions of Django and/or Python? – Clothespress

I've never run into issues using it against Python 2 (specifically 2.4-2.7). I used it just a few days ago, in fact. I've never tried with Python 3. – Puckett

I'm running django 1.8 on python 2.7 and I can't get epdb.connect to talk to epdb.serve. I just get a timeout. – Beisel

Answer 16

One of your best option to debug Django code is via wdb: https://github.com/Kozea/wdb

wdb works with python 2 (2.6, 2.7), python 3 (3.2, 3.3, 3.4, 3.5) and pypy. Even better, it is possible to debug a python 2 program with a wdb server running on python 3 and vice-versa or debug a program running on a computer with a debugging server running on another computer inside a web page on a third computer! Even betterer, it is now possible to pause a currently running python process/thread using code injection from the web interface. (This requires gdb and ptrace enabled) In other words it's a very enhanced version of pdb directly in your browser with nice features.

Install and run the server, and in your code add:

import wdb
wdb.set_trace()

According to the author, main differences with respect to pdb are:

For those who don’t know the project, wdb is a python debugger like pdb, but with a slick web front-end and a lot of additional features, such as:

• Source syntax highlighting
• Visual breakpoints
• Interactive code completion using jedi
• Persistent breakpoints
• Deep objects inspection using mouse Multithreading / Multiprocessing support
• Remote debugging
• Watch expressions
• In debugger code edition
• Popular web servers integration to break on error
• In exception breaking during trace (not post-mortem) in contrary to the werkzeug debugger for instance
• Breaking in currently running programs through code injection (on supported systems)

It has a great browser-based user interface. A joy to use! :)

Nightshirt

What is the difference with pdb? – Ectropion

Answer 17

I use PyCharm and different debug tools. Also have a nice articles set about easy set up those things for novices. You may start here. It tells about PDB and GUI debugging in general with Django projects. Hope someone would benefit from them.

Tunesmith

Answer 18

If using Aptana for django development, watch this: http://www.youtube.com/watch?v=qQh-UQFltJQ

If not, consider using it.

Maldives

Answer 19

Most options are alredy mentioned. To print template context, I've created a simple library for that. See https://github.com/edoburu/django-debugtools

You can use it to print template context without any {% load %} construct:

{% print var %}   prints variable
{% print %}       prints all

It uses a customized pprint format to display the variables in a <pre> tag.

Twannatwattle

Answer 20

I find Visual Studio Code is awesome for debugging Django apps. The standard python launch.json parameters run python manage.py with the debugger attached, so you can set breakpoints and step through your code as you like.

Articulator

Answer 21

For those that can accidentally add pdb into live commits, I can suggest this extension of #Koobz answer:

@register.filter 
def pdb(element):
    from django.conf import settings
    if settings.DEBUG:    
        import pdb
        pdb.set_trace()
    return element

Brotherhood

Answer 22

From my own experience , there are two way:

1. use ipdb,which is a enhanced debugger likes pdb.

   import ipdb;ipdb.set_trace() or breakpoint() (from python3.7)

2. use django shell ,just use the command below. This is very helpfull when you are developing a new view.

   python manage.py shell

Toponym

Answer 23

i highly suggest to use PDB.

import pdb
pdb.set_trace()

You can inspect all the variables values, step in to the function and much more. https://docs.python.org/2/library/pdb.html

for checking out the all kind of request,response and hits to database.i am using django-debug-toolbar https://github.com/django-debug-toolbar/django-debug-toolbar

Porshaport

Answer 24

As mentioned in other posts here - setting breakpoints in your code and walking thru the code to see if it behaves as you expected is a great way to learn something like Django until you have a good sense of how it all behaves - and what your code is doing.

To do this I would recommend using WingIde. Just like other mentioned IDEs nice and easy to use, nice layout and also easy to set breakpoints evaluate / modify the stack etc. Perfect for visualizing what your code is doing as you step through it. I'm a big fan of it.

Also I use PyCharm - it has excellent static code analysis and can help sometimes spot problems before you realize they are there.

As mentioned already django-debug-toolbar is essential - https://github.com/django-debug-toolbar/django-debug-toolbar

And while not explicitly a debug or analysis tool - one of my favorites is SQL Printing Middleware available from Django Snippets at https://djangosnippets.org/snippets/290/

This will display the SQL queries that your view has generated. This will give you a good sense of what the ORM is doing and if your queries are efficient or you need to rework your code (or add caching).

I find it invaluable for keeping an eye on query performance while developing and debugging my application.

Just one other tip - I modified it slightly for my own use to only show the summary and not the SQL statement.... So I always use it while developing and testing. I also added that if the len(connection.queries) is greater than a pre-defined threshold it displays an extra warning.

Then if I spot something bad (from a performance or number of queries perspective) is happening I turn back on the full display of the SQL statements to see exactly what is going on. Very handy when you are working on a large Django project with multiple developers.

Elvinelvina

Answer 25

use pdb or ipdb. Diffrence between these two is ipdb supports auto complete.

for pdb

import pdb
pdb.set_trace()

for ipdb

import ipdb
ipdb.set_trace()

For executing new line hit n key, for continue hit c key. check more options by using help(pdb)

Enteron

Answer 26

An additional suggestion.

You can leverage nosetests and pdb together, rather injecting pdb.set_trace() in your views manually. The advantage is that you can observe error conditions when they first start, potentially in 3rd party code.

Here's an error for me today.

TypeError at /db/hcm91dmo/catalog/records/

render_option() argument after * must be a sequence, not int

....


Error during template rendering

In template /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/crispy_forms/templates/bootstrap3/field.html, error at line 28
render_option() argument after * must be a sequence, not int
18  
19          {% if field|is_checkboxselectmultiple %}
20              {% include 'bootstrap3/layout/checkboxselectmultiple.html' %}
21          {% endif %}
22  
23          {% if field|is_radioselect %}
24              {% include 'bootstrap3/layout/radioselect.html' %}
25          {% endif %}
26  
27          {% if not field|is_checkboxselectmultiple and not field|is_radioselect %}
28  

      {% if field|is_checkbox and form_show_labels %}

Now, I know this means that I goofed the constructor for the form, and I even have good idea of which field is a problem. But, can I use pdb to see what crispy forms is complaining about, within a template?

Yes, I can. Using the --pdb option on nosetests:

tests$ nosetests test_urls_catalog.py --pdb

As soon as I hit any exception (including ones handled gracefully), pdb stops where it happens and I can look around.

  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/forms.py", line 537, in __str__
    return self.as_widget()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/forms.py", line 593, in as_widget
    return force_text(widget.render(name, self.value(), attrs=attrs))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/widgets.py", line 513, in render
    options = self.render_options(choices, [value])
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/widgets.py", line 543, in render_options
    output.append(self.render_option(selected_choices, *option))
TypeError: render_option() argument after * must be a sequence, not int
INFO lib.capture_middleware log write_to_index(http://localhost:8082/db/hcm91dmo/catalog/records.html)
INFO lib.capture_middleware log write_to_index:end
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/forms/widgets.py(543)render_options()
-> output.append(self.render_option(selected_choices, *option))
(Pdb) import pprint
(Pdb) pprint.PrettyPrinter(indent=4).pprint(self)
<django.forms.widgets.Select object at 0x115fe7d10>
(Pdb) pprint.PrettyPrinter(indent=4).pprint(vars(self))
{   'attrs': {   'class': 'select form-control'},
    'choices': [[('_', 'any type'), (7, (7, 'type 7', 'RECTYPE_TABLE'))]],
    'is_required': False}
(Pdb)         

Now, it's clear that my choices argument to the crispy field constructor was as it was a list within a list, rather than a list/tuple of tuples.

 'choices': [[('_', 'any type'), (7, (7, 'type 7', 'RECTYPE_TABLE'))]]

The neat thing is that this pdb is taking place within crispy's code, not mine and I didn't need to insert it manually.

Relativity

Answer 27

During development, adding a quick

assert False, value

can help diagnose problems in views or anywhere else, without the need to use a debugger.

Unconditional