GDB-like Python3 Debugger in the Trepan family
This is a gdb-like debugger for Python. It is a rewrite of pdb from the ground up.
A command-line interface (CLI) is provided as well as an remote access interface over TCP/IP.
There’s a lot of cool stuff here that’s not in the stock Python debugger pdb.
Python reports line information on the granularity of a line. To get more precise information, we can (de)parse into Python the byte code around a bytecode offset such as the place you are stopped at.
So far as I know, there is no other debugger that can do this.
Starting with release 0.2.0, terminal source code is colorized via pygments . And with that you can set the pygments color style, e.g. colorful, paraiso-dark. See set_style . Furthermore, we make use of terminal bold and emphasized text in debugger output and help text. Of course, you can also turn this off. Starting with release 0.6.0, you can use your own pygments_style, provided you have a terminal that supports 256 colors. If your terminal supports the basic ANSI color sequences only, we support that too in both dark and light themes.
Starting with release 2.8, readline command completion has been added. Command completion is not just a simple static list, but varies depending on the context. For example, for frame-changing commands which take optional numbers, on the list of valid numbers is considered.
We can adjust debugger output depending on the line width of your terminal. If it changes, or you want to adjust it, see set_width .
Starting with release 0.2.0, if you want to evaluate the current source line before it is run in the code, use eval. To evaluate text of a common fragment of line, such as the expression part of an if statement, you can do that with eval?. See eval for more information.
Sometimes you want small steps, and sometimes large stepping.
This fundamental issue is handled in a couple ways:
There are now step event and next event commands with aliases to s+, s> and so on. The plus-suffixed commands force a different line on a subsequent stop, the dash-suffixed commands don’t. Suffixes >, <, and ! specify call, return and exception events respectively. And without a suffix you get the default; this is set by the set different command.
By default the debugger stops at every event: call, return, line, exception, c-call, c-exception. If you just want to stop at line events (which is largely what you happens in pdb) you can. If however you just want to stop at calls and returns, that’s possible too. Or pick some combination.
In conjunction with handling all events by default, the event status is shown when stopped. The reason for stopping is also available via info program.
I’m not sure why this was not done before. Probably because of the lack of the ability to set and move by different granularities, tracing calls and returns lead to too many uninteresting stops (such as at the same place you just were at). Also, stopping on function definitions probably also added to this tedium.
Because we’re really handling return events, we can show you the return value. (pdb has an “undocumented” retval command that doesn’t seem to work.)
Starting with release 0.2.3, there are debugger macros. In gdb, there is a macro debugger command to extend debugger commands.
However Python has its own rich programming language so it seems silly to recreate the macro language that is in gdb. Simpler and more powerful is just to use Python here. A debugger macro here is just a lambda expression which returns a string or a list of strings. Each string returned should be a debugger command.
We also have aliases for the extremely simple situation where you want to give an alias to an existing debugger command. But beware: some commands, like step inspect command suffixes and change their behavior accordingly.
We also envision a number of other ways to allow extension of this debugger either through additional modules, or user-supplied debugger command directories.
If what you were looking for in macros was more front-end control over the debugger, then consider using the experimental (and not finished) Bullwinkle protocol.
We do more in the way of looking at the byte codes to give better information. Through this we can provide:
Even without “deparsing” mentioned above, the abilty to disassemble by line number range or byte-offset range lets you tell exactly where you are and code is getting run.
Commands that take integer arguments like up, list or disassemble allow you to use a Python expression which may include local or global variables that evaluates to an integer. This eliminates the need in gdb for special “dollar” debugger variables. (Note however because of shlex parsing ,expressions can’t have embedded blanks.)
You can now debug your program in a different process or even a different computer on a different network!
Can be installed via the usual pip or easy_install. There is a source tarball. How To Install has full instructions and installing from git and by other means.
The Debugger plays nice with other trace hooks. You can have several debugger objects.
Many of the things listed below doesn’t directly effect end-users, but it does eventually by way of more robust and featureful code. And keeping developers happy is a good thing.(TM)
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
|File Name & Checksum SHA256 Checksum Help||Version||File Type||Upload Date|
|trepan3k-0.7.6-py3.5.egg (607.2 kB) Copy SHA256 Checksum SHA256||3.5||Egg||Jun 22, 2017|
|trepan3k-0.7.6-py3-none-any.whl (308.4 kB) Copy SHA256 Checksum SHA256||3.5||Wheel||Jun 22, 2017|
|trepan3k-0.7.6.tar.gz (458.8 kB) Copy SHA256 Checksum SHA256||–||Source||Jun 22, 2017|