HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
django-commons
django-debug-toolbar
Python2013–2023
django-commons / django-debug-toolbar

django-debug-toolbar

A configurable set of panels that display various debug information about the current request/response.

Web Development
Explore on GitHubRead Hacker News discussions
12Distinct people
13Mentions
0Explicit recommenders
8.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A configurable set of panels that display various debug information about the current request/response.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year13 dated mentions

Observed mentions: 2013-11-03 03:15:51 UTC to 2023-02-08 11:35:36 UTC.

012342013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC404
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC303
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC101
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC303
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101

What Hacker News says

13 sources
scwoodal·Jan 18, 2022
When releasing a new application (or feature) I've always loaded each table in my development environments database with a few million rows. Tools like Python's Factory Boy [1] or Ruby's Factory Bot [2] help get the data loaded. After the data is loaded up, start navigating through the application and it will become evident where improvements need to be made. Tools like Django Debug Toolbar [3] help expose where the bad ORM calls are or also by tailing Postgres log files. [1] https://github.com/FactoryBoy/factory_boy [2] https://github.com/thoughtbot/factory_bot [3] https://github.com/jazzband/django-debug-toolbar
In PostgreSQL query performance bottlenecks
tony·Jun 7, 2017
Build it in parallel with your current codebase. If you're not doing so already, create a staging database you can use for developing this. That way if something goes berserk production data stays safe. Get a jumpstart by using Django and creating models that match your database via inspectdb [1]. Most important thing is getting the data to fit and relate as you'd expect. Some recommended plugins are django-debug-toolbar (https://github.com/jazzband/django-debug-toolbar) and django-extensions (https://github.com/django-extensions/django-extensions). Then for Social API logins use https://python-social-auth-docs.readthedocs.io. For Social API's themselves there are python wrappers, like https://github.com/mobolic/facebook-sdk. In the worst case, you'll be querying API's directly with requests (http://docs.python-requests.org). Next, you b
Read the rest
egin to build views (and their templates) around the models you've created. You're going to want them to run at a parity with what you have in PHP. Use urls.py regular expressions to match your URL's too. This is how you mitigate the risk of doing a "migration". And also a great way to get some experience under the belt while you do it. You should be able to get your site working off a staging database in a read-only way when you do this. Keep the PHP site in production until your ready to switch. If you use JSON/REST, also check out Django REST Framework. http://www.django-rest-framework.org/ I'm going to be making a detailed blog post on django in a few days as well. [1] https://docs.djangoproject.com/en/1.11/howto/legacy-database...
In Ask HN: Relaunch my website in Ruby/Python or continue with PHP?
tony·Apr 3, 2017
You can get pretty far with Flask. You'll need an ORM, so you'll likely chuck SQLAlchemy in. Then you'll want easier access to SQLAlchemy, sorta like, you know, django does it, so you pick up https://github.com/mitsuhiko/flask-sqlalchemy. But you can't use pure SQLAlchemy models (easily), since this otherwise great extension for flask doesn't support it (https://github.com/mitsuhiko/flask-sqlalchemy/pull/250, yes I'm in the thread). You'll fork it or brew your own code to get declarative models working right. Kinda time consuming, but at least your models can be pulled in by any python code, and aren't tied down to a framework (That's what you were avoiding from the first place, wasn't it?) Then you'll pick up WTForms (https://wtforms.readthedocs.io/en/latest/), another excellent library. And you'll miss having Django ORM's rich form and
Read the rest
model-backed validation. So you'll try wtforms-alchemy, https://github.com/kvesteri/wtforms-alchemy. Then you'll begin to see why Django makes sense after using Flask for a while. Django pulls in all the essential stuff and supports it well. And top of that, django's addons like django-extensions (https://django-extensions.readthedocs.io), which gives you Werkzeug's debugger if you use ./manage.py runserver_plus. And ./manage.py shell_plus, which integrates with ptpython/ipython/bpython (https://django-extensions.readthedocs.io/en/latest/shell_plu...). Django rest framework, DRF for short (http://www.django-rest-framework.org/), which is very mature at this stage, runs circles around Flask API. Flask API is inspired by DRF. You could also try https://flask-restful.readthedocs.io, but after all that, you'll be missing that tight model support. You'll love flask. The code is top tier and exemplary. The testsuites are a dream and are very clear. Documentation is awesome. It feels good to code in it. But django feels good to code in as well. Django's ORM is very mature. It's easier than SQLAlchemy, and despite SQLAlchemy's purity, and documentation - even better than flask's - Django's ORM does the trick for pretty much anything, even foreign databases I've interacted with. Another thing, QuerySet's are a charm, a lot of django's addons like django-filters, django-rest-framework and django-tables2 are built on top of its versatility. Another thing Flask community ends up having to clone from Django is django-debug-toolbar https://github.com/django-debug-toolbar/django-debug-toolbar. See https://flask-debugtoolbar.readthedocs.io. Again, I love flask, but when I realized that I'm just going to end up reinventing django with my flask app anyway, I started going with django on new projects. I haven't turned back, but still check out flask and sqlalchemy to see what's happening now and then.
In Ask HN: Django vs. Flask
antod·Jan 20, 2016
In terms of web debugging instead of general code debugging tools mentioned by others, the common Python frameworks have toolbars based on Armin's Werkzeug one: http://werkzeug.pocoo.org/docs/dev/debug/ eg... For Pyramid: http://docs.pylonsproject.org/projects/pyramid-debugtoolbar/... For Flask: http://flask-debugtoolbar.readthedocs.org/en/latest/ For Django: https://github.com/django-debug-toolbar/django-debug-toolbar I have no idea how well they compare to equivalent Rails tools though.
In The Rails Doctrine

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.