Top Related Projects
Quick Overview
ipdb is an enhanced Python debugger that integrates IPython's features into the standard Python debugger (pdb). It provides a more user-friendly and feature-rich debugging experience, including syntax highlighting, tab completion, and better introspection capabilities.
Pros
- Enhanced debugging experience with IPython features
- Syntax highlighting and tab completion for easier code navigation
- Improved introspection and variable exploration
- Seamless integration with existing Python debugging workflows
Cons
- Requires additional dependencies (IPython)
- May have a slight performance overhead compared to the standard pdb
- Learning curve for users unfamiliar with IPython features
- Not included in the Python standard library
Code Examples
- Setting a breakpoint in your code:
import ipdb
def my_function():
x = 10
y = 20
ipdb.set_trace() # Debugger will pause here
result = x + y
return result
my_function()
- Using ipdb as a post-mortem debugger:
import ipdb
def divide(a, b):
return a / b
try:
result = divide(10, 0)
except Exception:
ipdb.post_mortem() # Start debugger after an exception occurs
- Running a script with ipdb from the command line:
python -m ipdb my_script.py
Getting Started
To get started with ipdb, follow these steps:
-
Install ipdb using pip:
pip install ipdb
-
Import ipdb in your Python script:
import ipdb
-
Set a breakpoint using
ipdb.set_trace()
:def my_function(): x = 10 ipdb.set_trace() # Debugger will pause here y = x + 5 return y
-
Run your script, and when the breakpoint is hit, you'll enter the ipdb interactive debugger.
Competitor Comparisons
pdb++, a drop-in replacement for pdb (the Python debugger)
Pros of pdbpp
- More feature-rich with syntax highlighting, tab completion, and sticky mode
- Actively maintained with regular updates and bug fixes
- Supports both Python 2 and Python 3
Cons of pdbpp
- Slightly more complex setup and configuration
- May have a steeper learning curve for beginners
- Some features might be considered "overkill" for simple debugging tasks
Code Comparison
pdbpp:
import pdb
pdb.set_trace()
ipdb:
import ipdb
ipdb.set_trace()
Both libraries use similar syntax for setting breakpoints, but pdbpp offers additional features like:
# pdbpp-specific command
sticky() # Enter sticky mode
pdbpp provides a more enhanced debugging experience with its additional features, while ipdb focuses on simplicity and integration with IPython. pdbpp is actively maintained and supports both Python 2 and 3, making it a more versatile choice for many developers. However, ipdb's simplicity and ease of use might be preferred for quick debugging sessions or by those who are already familiar with IPython's interface.
An implementation of the Debug Adapter Protocol for Python
Pros of debugpy
- More comprehensive debugging capabilities, including remote debugging and multi-threaded debugging
- Actively maintained with regular updates and improvements
- Integrates well with popular IDEs and development environments
Cons of debugpy
- Steeper learning curve due to more complex features
- Heavier resource usage compared to ipdb's lightweight approach
- May be overkill for simple debugging tasks
Code Comparison
ipdb:
import ipdb
ipdb.set_trace()
# Your code here
debugpy:
import debugpy
debugpy.listen(5678)
debugpy.wait_for_client()
# Your code here
Key Differences
- ipdb is a simple, interactive debugger that enhances the built-in pdb
- debugpy is a full-featured debugging package with advanced capabilities
- ipdb focuses on ease of use and quick debugging sessions
- debugpy offers more control and flexibility for complex debugging scenarios
Use Cases
- ipdb: Quick debugging of small scripts or specific code sections
- debugpy: Debugging large projects, remote debugging, or integration with IDEs
Community and Support
- ipdb has a smaller but dedicated community
- debugpy benefits from Microsoft's backing and larger user base
Performance
- ipdb is lightweight and starts quickly
- debugpy may have slightly longer startup times but offers better performance for complex debugging tasks
Never use print for debugging again
Pros of PySnooper
- Non-intrusive debugging: Automatically logs variables and execution flow without modifying code
- Customizable output: Allows specifying variables to watch and output destinations
- Works with any Python environment: No special IDE or debugger required
Cons of PySnooper
- Performance overhead: Logging all variables can slow down execution
- Less interactive: Doesn't provide real-time debugging or breakpoints
- Limited control: Lacks advanced features like conditional breakpoints or step-through debugging
Code Comparison
PySnooper:
import pysnooper
@pysnooper.snoop()
def calculate_factorial(n):
if n == 0:
return 1
return n * calculate_factorial(n - 1)
ipdb:
import ipdb
def calculate_factorial(n):
ipdb.set_trace()
if n == 0:
return 1
return n * calculate_factorial(n - 1)
PySnooper automatically logs the function execution, while ipdb requires manual insertion of breakpoints. PySnooper provides a higher-level overview of the program flow, whereas ipdb offers more fine-grained control over the debugging process.
Full-screen console debugger for Python
Pros of pudb
- Full-screen, console-based interface with a visual display of source code, variables, and stack
- Supports remote debugging over SSH
- Customizable interface with themes and keyboard shortcuts
Cons of pudb
- Steeper learning curve due to more complex interface
- May be overkill for simple debugging tasks
- Requires additional setup for remote debugging
Code comparison
pudb:
import pudb
pudb.set_trace()
# Your code here
ipdb:
import ipdb
ipdb.set_trace()
# Your code here
Key differences
- Interface: pudb offers a full-screen, visual interface, while ipdb provides a command-line interface similar to pdb
- Features: pudb includes advanced features like remote debugging and customizable themes, whereas ipdb focuses on enhancing the standard pdb experience
- Ease of use: ipdb is generally easier to set up and use for quick debugging sessions, while pudb offers more powerful features at the cost of complexity
Both debuggers serve different needs and preferences. ipdb is ideal for those familiar with pdb and seeking a more interactive experience, while pudb caters to users who prefer a visual, feature-rich debugging environment.
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
IPython pdb
.. image:: https://github.com/gotcha/ipdb/actions/workflows/tests.yml/badge.svg :target: https://github.com/gotcha/ipdb/actions/workflows/tests.yml .. image:: https://codecov.io/gh/gotcha/ipdb/branch/master/graphs/badge.svg?style=flat :target: https://codecov.io/gh/gotcha/ipdb?branch=master
Use
ipdb exports functions to access the IPython_ debugger, which features
tab completion, syntax highlighting, better tracebacks, better introspection
with the same interface as the pdb
module.
Example usage:
.. code-block:: python
import ipdb
ipdb.set_trace()
ipdb.set_trace(context=5) # will show five lines of code
# instead of the default three lines
# or you can set it via IPDB_CONTEXT_SIZE env variable
# or setup.cfg file
ipdb.pm()
ipdb.run('x[0] = 3')
result = ipdb.runcall(function, arg0, arg1, kwarg='foo')
result = ipdb.runeval('f(1,2) - 3')
Arguments for set_trace
+++++++++++++++++++++++++
The set_trace
function accepts context
which will show as many lines of code as defined,
and cond
, which accepts boolean values (such as abc == 17
) and will start ipdb's
interface whenever cond
equals to True
.
Using configuration file ++++++++++++++++++++++++
It's possible to set up context using a .ipdb
file on your home folder, setup.cfg
or pyproject.toml
on your project folder. You can also set your file location via
env var $IPDB_CONFIG
. Your environment variable has priority over the home
configuration file, which in turn has priority over the setup config file.
Currently, only context setting is available.
A valid setup.cfg is as follows
::
[ipdb]
context=5
A valid .ipdb is as follows
::
context=5
A valid pyproject.toml is as follows
::
[tool.ipdb]
context=5
The post-mortem function, ipdb.pm()
, is equivalent to the magic function
%debug
.
.. _IPython: http://ipython.org
If you install ipdb
with a tool which supports setuptools
entry points,
an ipdb
script is made for you. You can use it to debug your python 2 scripts like
::
$ bin/ipdb mymodule.py
And for python 3
::
$ bin/ipdb3 mymodule.py
Alternatively with Python 2.7 only, you can also use
::
$ python -m ipdb mymodule.py
You can also enclose code with the with
statement to launch ipdb if an exception is raised:
.. code-block:: python
from ipdb import launch_ipdb_on_exception
with launch_ipdb_on_exception():
[...]
.. warning::
Context managers were introduced in Python 2.5.
Adding a context manager implies dropping Python 2.4 support.
Use ipdb==0.6
with 2.4.
Or you can use iex
as a function decorator to launch ipdb if an exception is raised:
.. code-block:: python
from ipdb import iex
@iex
def main():
[...]
.. warning::
Using from future import print_function
for Python 3 compat implies dropping Python 2.5 support.
Use ipdb<=0.8
with 2.5.
Issues with stdout
Some tools, like nose
fiddle with stdout
.
Until ipdb==0.9.4
, we tried to guess when we should also
fiddle with stdout
to support those tools.
However, all strategies tried until 0.9.4 have proven brittle.
If you use nose
or another tool that fiddles with stdout
, you should
explicitly ask for stdout
fiddling by using ipdb
like this
.. code-block:: python
import ipdb
ipdb.sset_trace()
ipdb.spm()
from ipdb import slaunch_ipdb_on_exception
with slaunch_ipdb_on_exception():
[...]
Development
ipdb
source code and tracker are at https://github.com/gotcha/ipdb.
Pull requests should take care of updating the changelog HISTORY.txt
.
Under the unreleased section, add your changes and your username.
Manual testing ++++++++++++++
To test your changes, make use of manual_test.py
. Create a virtual environment,
install IPython and run python manual_test.py
and check if your changes are in effect.
If possible, create automated tests for better behaviour control.
Automated testing +++++++++++++++++
To run automated tests locally, create a virtual environment, install coverage
and run coverage run setup.py test
.
Third-party support
Products.PDBDebugMode +++++++++++++++++++++
Zope2 Products.PDBDebugMode_ uses ipdb
, if available, in place of pdb
.
.. _Products.PDBDebugMode: http://pypi.python.org/pypi/Products.PDBDebugMode
iw.debug ++++++++
iw.debug_ allows you to trigger an ipdb
debugger on any published object
of a Zope2 application.
.. _iw.debug: http://pypi.python.org/pypi/iw.debug
ipdbplugin ++++++++++
ipdbplugin_ is a nose_ test runner plugin that also uses the IPython debugger
instead of pdb
. (It does not depend on ipdb
anymore).
.. _ipdbplugin: http://pypi.python.org/pypi/ipdbplugin .. _nose: http://readthedocs.org/docs/nose
pytest
+++++++
pytest_ supports a --pdb
option which can run ipdb
/
IPython.terminal.debugger:Pdb
on Exception
and breakpoint()
:
.. code:: bash
pytest --pdb --pdbcls=IPython.terminal.debugger:Pdb -v ./test_example.py
You don't need to specify --pdbcls
for every pytest
invocation
if you add addopts
to pytest.ini
or pyproject.toml
.
pytest.ini
:
.. code:: bash
[tool.pytest.ini_options] addopts = "--pdbcls=IPython.terminal.debugger:Pdb"
pyproject.toml
:
.. code:: yml
[tool.pytest.ini_options] addopts = "--pdbcls=IPython.terminal.debugger:Pdb"
.. _pytest: https://pypi.python.org/pypi/pytest
Top Related Projects
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot