trepan3k

Name	trepan3k JSON
Version	1.3.0 JSON
	download
home_page	http://github.com/rocky/python3-trepan/
Summary	GDB-like Python Debugger in the Trepan family
upload_time	2024-11-13 15:53:30
maintainer	None
docs_url	None
author	Rocky Bernstein
requires_python	None
license	GPL3
keywords
VCS
bugtrack_url
requirements	columnize
Travis-CI
coveralls test coverage

|packagestatus|

.. contents:: :local:

Abstract
========

This is a gdb-like debugger for Python. It is a rewrite of *pdb* from
the ground up. I was disappointed with the flakiness, imprecision, and
poor quality of coding, modularity, and level of documentation when I
first looked at *pdb*. (*pdb* has gotten better since then. But a full
and complete debugger, is way more complex than what you'd expect from
a Standard Python module; it requires a larger set of supporting
packages too than is found in the Standard Python library).

``trepan3k`` is both a high-level debugger as well as a lower-level
bytecode debugger inspector. The code understands a lot about byte
code and the Python code object. The debugger makes use of this
knowledge to get more precise and accurate results and provide more
reliable operations.

A command-line interface (CLI) is provided as well as remote access
interface over TCP/IP.

See the entry-exit_ for the various ways you can enter the debugger.

This code supports versions of Python back to version 3.0 using
different *git* branches. See trepan2_ for the same code modified to
work with Python 2.

Features
========

Since this debugger is similar to other_ trepanning_ debuggers_ and *gdb*
in general, knowledge gained by learning this is transferable to those
debuggers and vice versa.

There's a lot of cool stuff here that's not in the stock
Python debugger *pdb*, or any other Python debugger that I know about.

More Exact location information
-------------------------------

Python reports line information on the granularity of a line. For
Python versions up to 3.8, 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 decompiles code at
runtime to narrow position down to the specific bytecode
instruction.

See the deparse_ command for details on getting this kind of
information.

The problem with deparsing after 3.8 is that there is no decompiler
that can deparse code and give associations to bytecode
instructions. I am slowly working on that though.

We use information in Python's code object line number table in byte
to understand which lines are breakpointable, and in which module or
function the line appears in. Use info-line_ to see this
information. Most if not all other debuggers do go to such lengths,
and as a result, it is possible to request stopping on a line number
that can never occur without complaint.

In the future, we may allow specifying an offset to indicate which
offset to stop at when there are several choices for a given line
number.

Debugging Python bytecode (no source available)
-----------------------------------------------

You can pass the debugger the name of Python bytecode and many times,
the debugger will merrily proceed. This debugger tries very hard to
find the source code. Either by using the current executable search
path (e.g. ``PATH``) or for some by looking inside the bytecode for a
filename in the main code object (``co_filename``) and applying that
with a search path that takes into account the directory where the
bytecode lives.

Failing to find source code this way, and in other situations where
source code can't be found, the debugger will decompile the bytecode
and use that for showing the source text. *This allows us to debug ``eval``'d
or ``exec``'d code.*

But if you happen to know where the source code is located, you can
associate a file source code with the current name listed in the
bytecode. See the set-substitute_ command for details here.

Source-code Syntax Colorization
-------------------------------

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. 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.

Command Completion
------------------

Command completion is available for GNU readline and
``prompt_toolkit``. While prompt_toolkit is new, command completion for
GNU Readline is not just a simple static list but varies depending on
the context. For example, for frame-changing commands that take
optional numbers, the list of *valid numbers* is considered.

In time (and perhaps with some volunteers), ``prompt_toolkit``
completion will be as good as GNU Readline completion.

Terminal Handling
-----------------

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_.

Signal Handling
-----------------

Following *gdb*, we provide its rich set of signal handling. From the *gdb* documentation:

GDB has the ability to detect any occurrence of a signal in your program. You can tell GDB in advance what to do for each kind of signal.

Better Support for Thread Debugging
------------------------------------

When you are stopped inside a thread, the thread name is shown to make
this fact more clear and you can see and switch between frames in
different threads. See frame_ for more information.

And following *gdb*, you can list the threads too. See info-threads_ for more information.

Smart Eval
----------

If you want to evaluate the current source line before it is run in
the code, use ``eval``. To evaluate the text of a common fragment of a
line, such as the expression part of an *if* statement, you can do
that with ``eval?``. See eval_ for more information.

Function Breakpoints
---------------------

Many Python debuggers only allow setting a breakpoint at a line event
and functions are treated like line numbers. But functions and lines
are fundamentally different. If I write::

def five(): return 5

this line contains three different kinds of things. First, there is
the code in Python that defines the function ``five()`` for the first
time. Then there is the function itself, and then there is some code
inside that function.

In this debugger, you can give the name of a *function* by surrounding
adding ``()`` at the end::

break five()

Also ``five`` could be a method of an object that is currently defined when the
``breakpoint`` command is given::

self.five()

More Stepping Control
---------------------

Sometimes you want small steps, and sometimes large steps.

This fundamental issue is handled in a couple of ways:

Step Granularity
................

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.

Event Filtering and Tracing
...........................

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 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``.

Event Tracing of Calls and Returns
----------------------------------

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 leads 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 stop on the
return. This is a little more precise than *pdb*'s *retval* command.

Debugger Macros via Python Lambda expressions
---------------------------------------------

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 that 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 provide extending the debugger either through additional Python packages.

Byte-code Instruction Introspection
------------------------------------

We do more in the way of looking at the byte codes to give better information. Through this, we can provide:

* a *skip* command. It is like the *jump* command, but you don't have
to deal with line numbers.
* disassembly of code fragments. You can now disassemble relative to
the stack frames you are currently stopped at.
* Better interpretation of where you are when inside *execfile* or
*exec*. (But really though this is probably a Python compiler
misfeature.)
* Check that breakpoints are set only where they make sense.
* A more accurate determination of if you are at a function-defining
*def* or *class* statements (because the caller's instruction contains
``MAKE_FUNCTION`` or ``BUILD_CLASS``.)

Even without "deparsing" mentioned above, the ability to disassemble
where the PC is currently located (see info-pc_), by line
number range or byte-offset range lets you tell exactly where you are
and code is getting run.

Some Debugger Command Arguments can be Variables and Expressions
----------------------------------------------------------------

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 evaluate 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.)

Out-of-Process Debugging
------------------------

You can now debug your program in a different process or even a different computer on a different network!

Related, is flexible support for remapping path names from the file
system, e.g. the filesystem seen inside a docker container or on a remote filesystem
with locally-installed files. See subst_ for more information.

Egg, Wheel, and Tarballs
------------------------

Can be installed via the usual *pip* or *easy_install*. There is a
source tarball. `How To Install
<https://python3-trepan.readthedocs.io/en/latest/install.html>`_ has
full instructions and installation using *git* or by other means.

Modularity
----------

Because this debugger is modular, I have been able to use it as the basis
for debuggers in other projects. In particular, it is used as a module in trepanxpy_, a debugger for Python interpreter, x-python_, written in Python.

It is also used as a module inside an experimental open-source Wolfram Mathematica interpreter, Mathics3_.

Using pytracer_, the Debugger plays nice with other trace hooks. You
can have several debugger objects.

Many of the things listed below do not directly impact end-users, but
it does eventually by way of more robust and featureful code. And
keeping developers happy is a good thing.(TM)

* Commands and subcommands are individual classes now, not methods in a class. This means they now have properties like the context in which they can be run, minimum abbreviation names, or alias names. To add a new command you basically add a file in a directory.
* I/O is its own layer. This simplifies interactive readline behavior from reading commands over a TCP socket.
* An interface is its own layer. Local debugging, remote debugging, and running debugger commands from a file (``source``) are different interfaces. This means, for example, that we are able to give better error reporting if a debugger command file has an error.
* There is an experimental Python-friendly interface for front-ends
* more testable. Much more unit and functional tests.

Documentation
-------------

Documentation: http://python3-trepan.readthedocs.org

Raw data

            {
    "_id": null,
    "home_page": "http://github.com/rocky/python3-trepan/",
    "name": "trepan3k",
    "maintainer": null,
    "docs_url": null,
    "requires_python": null,
    "maintainer_email": null,
    "keywords": null,
    "author": "Rocky Bernstein",
    "author_email": "rocky@gnu.org",
    "download_url": "https://files.pythonhosted.org/packages/a4/9e/e7018176cec5b3994c180b30665774c5fec2d560d30b8633de3f54a5a69b/trepan3k-1.3.0.tar.gz",
    "platform": null,
    "description": "|CircleCI| |Pypi Installs| |license| |docs| |Supported Python Versions|\n\n|packagestatus|\n\n.. contents:: :local:\n\nAbstract\n========\n\nThis is a gdb-like debugger for Python. It is a rewrite of *pdb* from\nthe ground up. I was disappointed with the flakiness, imprecision, and\npoor quality of coding, modularity, and level of documentation when I\nfirst looked at *pdb*. (*pdb* has gotten better since then. But a full\nand complete debugger, is way more complex than what you'd expect from\na Standard Python module; it requires a larger set of supporting\npackages too than is found in the Standard Python library).\n\n``trepan3k`` is both a high-level debugger as well as a lower-level\nbytecode debugger inspector. The code understands a lot about byte\ncode and the Python code object. The debugger makes use of this\nknowledge to get more precise and accurate results and provide more\nreliable operations.\n\nA command-line interface (CLI) is provided as well as remote access\ninterface over TCP/IP.\n\nSee the entry-exit_ for the various ways you can enter the debugger.\n\nThis code supports versions of Python back to version 3.0 using\ndifferent *git* branches. See trepan2_ for the same code modified to\nwork with Python 2.\n\nFeatures\n========\n\nSince this debugger is similar to other_ trepanning_ debuggers_ and *gdb*\nin general, knowledge gained by learning this is transferable to those\ndebuggers and vice versa.\n\nThere's a lot of cool stuff here that's not in the stock\nPython debugger *pdb*, or any other Python debugger that I know about.\n\n\nMore Exact location information\n-------------------------------\n\nPython reports line information on the granularity of a line. For\nPython versions up to 3.8, To get more precise information, we can\n(de)parse into Python the byte code around a bytecode offset such as\nthe place you are stopped at.\n\nSo far as I know, there is no other debugger that decompiles code at\nruntime to narrow position down to the specific bytecode\ninstruction.\n\nSee the deparse_ command for details on getting this kind of\ninformation.\n\nThe problem with deparsing after 3.8 is that there is no decompiler\nthat can deparse code and give associations to bytecode\ninstructions. I am slowly working on that though.\n\nWe use information in Python's code object line number table in byte\nto understand which lines are breakpointable, and in which module or\nfunction the line appears in. Use info-line_ to see this\ninformation. Most if not all other debuggers do go to such lengths,\nand as a result, it is possible to request stopping on a line number\nthat can never occur without complaint.\n\nIn the future, we may allow specifying an offset to indicate which\noffset to stop at when there are several choices for a given line\nnumber.\n\n\nDebugging Python bytecode (no source available)\n-----------------------------------------------\n\nYou can pass the debugger the name of Python bytecode and many times,\nthe debugger will merrily proceed.  This debugger tries very hard to\nfind the source code. Either by using the current executable search\npath (e.g. ``PATH``) or for some by looking inside the bytecode for a\nfilename in the main code object (``co_filename``) and applying that\nwith a search path that takes into account the directory where the\nbytecode lives.\n\nFailing to find source code this way, and in other situations where\nsource code can't be found, the debugger will decompile the bytecode\nand use that for showing the source text. *This allows us to debug ``eval``'d\nor ``exec``'d code.*\n\nBut if you happen to know where the source code is located, you can\nassociate a file source code with the current name listed in the\nbytecode. See the set-substitute_ command for details here.\n\nSource-code Syntax Colorization\n-------------------------------\n\nTerminal source code is colorized via pygments_. And with that, you\ncan set the pygments color style, e.g. \"colorful\", \"paraiso-dark\". See\nset-style_ . Furthermore, we make use of terminal bold\nand emphasized text in debugger output and help text. Of course, you\ncan also turn this off. You can use your own pygments_style_, provided\nyou have a terminal that supports 256 colors. If your terminal\nsupports the basic ANSI color sequences only, we support that too in\nboth dark and light themes.\n\n\nCommand Completion\n------------------\n\nCommand completion is available for GNU readline and\n``prompt_toolkit``. While prompt_toolkit is new, command completion for\nGNU Readline is not just a simple static list but varies depending on\nthe context. For example, for frame-changing commands that take\noptional numbers, the list of *valid numbers* is considered.\n\nIn time (and perhaps with some volunteers), ``prompt_toolkit``\ncompletion will be as good as GNU Readline completion.\n\nTerminal Handling\n-----------------\n\nWe can adjust debugger output depending on the line width of your\nterminal. If it changes, or you want to adjust it, see set-width_.\n\nSignal Handling\n-----------------\n\nFollowing *gdb*, we provide its rich set of signal handling. From the *gdb* documentation:\n\n  GDB has the ability to detect any occurrence of a signal in your program. You can tell GDB in advance what to do for each kind of signal.\n\nBetter Support for Thread Debugging\n------------------------------------\n\nWhen you are stopped inside a thread, the thread name is shown to make\nthis fact more clear and you can see and switch between frames in\ndifferent threads. See frame_ for more information.\n\nAnd following *gdb*, you can list the threads too. See info-threads_ for more information.\n\n\nSmart Eval\n----------\n\nIf you want to evaluate the current source line before it is run in\nthe code, use ``eval``. To evaluate the text of a common fragment of a\nline, such as the expression part of an *if* statement, you can do\nthat with ``eval?``. See eval_ for more information.\n\nFunction Breakpoints\n---------------------\n\nMany Python debuggers only allow setting a breakpoint at a line event\nand functions are treated like line numbers. But functions and lines\nare fundamentally different. If I write::\n\n     def five(): return 5\n\nthis line contains three different kinds of things. First, there is\nthe code in Python that defines the function ``five()`` for the first\ntime. Then there is the function itself, and then there is some code\ninside that function.\n\nIn this debugger, you can give the name of a *function* by surrounding\nadding ``()`` at the end::\n\n    break five()\n\nAlso ``five`` could be a method of an object that is currently defined when the\n``breakpoint`` command is given::\n\n    self.five()\n\nMore Stepping Control\n---------------------\n\nSometimes you want small steps, and sometimes large steps.\n\nThis fundamental issue is handled in a couple of ways:\n\nStep Granularity\n................\n\nThere are now ``step`` *event* and ``next`` *event* commands with\naliases to ``s+``, ``s>``, and so on. The plus-suffixed commands force\na different line on a subsequent stop, the dash-suffixed commands\ndon't.  Suffixes ``>``, ``<``, and ``!`` specify ``call``, ``return``\nand ``exception`` events respectively. And without a suffix, you get\nthe default; this is set by the ``set different`` command.\n\nEvent Filtering and Tracing\n...........................\n\nBy default, the debugger stops at every event: ``call``, ``return``,\n``line``, ``exception``, ``c-call``, ``c-exception``. If you just want\nto stop at ``line`` events (which is largely what happens in\n*pdb*) you can. If however you just want to stop at calls and returns,\nthat's possible too. Or pick some combination.\n\nIn conjunction with handling *all* events by default, the event status is shown when stopped. The reason for stopping is also available via ``info program``.\n\nEvent Tracing of Calls and Returns\n----------------------------------\n\nI'm not sure why this was not done before. Probably because of the\nlack of the ability to set and move by different granularities,\ntracing calls and returns leads to too many uninteresting stops (such\nas at the same place you just were at). Also, stopping on function\ndefinitions probably also added to this tedium.\n\nBecause we're really handling return events, we can stop on the\nreturn. This is a little more precise than *pdb*'s *retval* command.\n\nDebugger Macros via Python Lambda expressions\n---------------------------------------------\n\nThere are debugger macros.  In *gdb*, there is a *macro* debugger\ncommand to extend debugger commands.\n\nHowever, Python has its own rich programming language so it seems silly\nto recreate the macro language that is in *gdb*. Simpler and more\npowerful is just to use Python here. A debugger macro here is just a\nlambda expression that returns a string or a list of strings. Each\nstring returned should be a debugger command.\n\nWe also have *aliases* for the extremely simple situation where you\nwant to give an alias to an existing debugger command. But beware:\nSome commands, like step_ inspect command suffixes and change their\nbehavior accordingly.\n\nWe also provide extending the debugger either through additional Python packages.\n\nByte-code Instruction Introspection\n------------------------------------\n\nWe do more in the way of looking at the byte codes to give better information. Through this, we can provide:\n\n* a *skip* command. It is like the *jump* command, but you don't have\n  to deal with line numbers.\n* disassembly of code fragments. You can now disassemble relative to\n  the stack frames you are currently stopped at.\n* Better interpretation of where you are when inside *execfile* or\n  *exec*. (But really though this is probably a Python compiler\n  misfeature.)\n* Check that breakpoints are set only where they make sense.\n* A more accurate determination of if you are at a function-defining\n  *def* or *class* statements (because the caller's instruction contains\n  ``MAKE_FUNCTION`` or ``BUILD_CLASS``.)\n\nEven without \"deparsing\" mentioned above, the ability to disassemble\nwhere the PC is currently located (see info-pc_), by line\nnumber range or byte-offset range lets you tell exactly where you are\nand code is getting run.\n\nSome Debugger Command Arguments can be Variables and Expressions\n----------------------------------------------------------------\n\nCommands that take integer arguments like *up*, *list*, or\n*disassemble* allow you to use a Python expression which may include\nlocal or global variables that evaluate to an integer. This\neliminates the need in *gdb* for special \"dollar\" debugger\nvariables. (Note however because of *shlex* parsing, expressions can't\nhave embedded blanks.)\n\nOut-of-Process Debugging\n------------------------\n\nYou can now debug your program in a different process or even a different computer on a different network!\n\nRelated, is flexible support for remapping path names from the file\nsystem, e.g. the filesystem seen inside a docker container or on a remote filesystem\nwith locally-installed files. See subst_ for more information.\n\nEgg, Wheel, and Tarballs\n------------------------\n\nCan be installed via the usual *pip* or *easy_install*. There is a\nsource tarball. `How To Install\n<https://python3-trepan.readthedocs.io/en/latest/install.html>`_ has\nfull instructions and installation using *git* or by other means.\n\nModularity\n----------\n\nBecause this debugger is modular, I have been able to use it as the basis\nfor debuggers in other projects. In particular, it is used as a module in trepanxpy_, a debugger for Python interpreter, x-python_, written in Python.\n\nIt is also used as a module inside an experimental open-source Wolfram Mathematica interpreter, Mathics3_.\n\nUsing pytracer_, the Debugger plays nice with other trace hooks. You\ncan have several debugger objects.\n\nMany of the things listed below do not directly impact end-users, but\nit does eventually by way of more robust and featureful code. And\nkeeping developers happy is a good thing.(TM)\n\n* Commands and subcommands are individual classes now, not methods in a class. This means they now have properties like the context in which they can be run, minimum abbreviation names, or alias names. To add a new command you basically add a file in a directory.\n* I/O is its own layer. This simplifies interactive readline behavior from reading commands over a TCP socket.\n* An interface is its own layer. Local debugging, remote debugging, and running debugger commands from a file (``source``) are different interfaces. This means, for example, that we are able to give better error reporting if a debugger command file has an error.\n* There is an experimental Python-friendly interface for front-ends\n* more testable. Much more unit and functional tests.\n\nDocumentation\n-------------\n\nDocumentation: http://python3-trepan.readthedocs.org\n\nSee Also\n--------\n\n* trepanxpy_: trepan debugger for `x-python <https://pypi.python.org/pypi/x-python>`_, the bytecode interpreter written in Python\n* https://github.com/rocky/trepan-xpy: Python debugger using this code to support `x-python <https://pypi.python.org/pypi/x-python>`_\n* https://pypi.python.org/pypi/uncompyle6: Python decompiler\n* https://pypi.python.org/pypi/decompyle3: Python 3.7 and 3.8 decompiler\n* https://pypi.python.org/pypi/xdis: cross-platform disassembler\n\n\n.. _pytracer: https://pypi.python.org/pypi/pytracer\n.. _x-python: https://pypi.python.org/pypi/x-python\n.. _Mathics3:  https://mathics.org\n.. _pygments:  https://pygments.org\n.. _pygments_style:  https://pygments.org/docs/styles/\n.. _howtoinstall: https://github.com/rocky/python3-trepan/wiki/How-to-Install\n.. _pydb:  https://bashdb.sf.net/pydb\n.. _pydbgr: https://pypi.python.org/pypi/pydbgr\n.. _trepan2: https://pypi.python.org/pypi/trepan2\n.. _trepan3: https://github.com/rocky/python3-trepan\n.. _trepanxpy: https://pypi.python.org/pypi/trepanxpy\n.. _other: https://repology.org/project/zshdb/versions\n.. _trepanning: https://rubygems.org/gems/trepanning\n.. _debuggers: https://metacpan.org/pod/Devel::Trepan\n.. _this: https://bashdb.sourceforge.net/pydb/features.html\n.. _entry-exit: https://python3-trepan.readthedocs.io/en/latest/entry-exit.html\n.. _trepanxpy: https://pypi.python.org/pypi/trepanxpy\n.. |downloads| image:: https://img.shields.io/pypi/dd/trepan3k.svg\n   :target: https://pypi.python.org/pypi/trepan3k/\n.. |CircleCI| image:: https://circleci.com/gh/Trepan-Debuggers/python3-trepan/tree/master.svg?style=svg\n        :target: https://app.circleci.com/pipelines/github/Trepan-Debuggers/python3-trepan\n.. _ipython-trepan: https://github.com/rocky/ipython-trepan\n.. |license| image:: https://img.shields.io/pypi/l/trepan.svg\n    :target: https://pypi.python.org/pypi/trepan3k\n    :alt: License\n.. _deparse:  https://python3-trepan.readthedocs.io/en/latest/commands/data/deparse.html\n.. _info-line:  https://python3-trepan.readthedocs.io/en/latest/commands/info/line.html\n.. _info-pc:  https://python3-trepan.readthedocs.io/en/latest/commands/info/pc.html\n.. _info-threads:  https://python3-trepan.readthedocs.io/en/latest/commands/info/threads.html\n.. _frame:  https://python3-trepan.readthedocs.io/en/latest/commands/stack/frame.html\n.. _set-style:  https://python3-trepan.readthedocs.org/en/latest/commands/set/style.html\n.. _set-substitute:  https://python3-trepan.readthedocs.org/en/latest/commands/set/substitute.html\n.. _set-width:  https://python3-trepan.readthedocs.org/en/latest/commands/set/width.html\n.. _eval: https://python3-trepan.readthedocs.org/en/latest/commands/data/eval.html\n.. _step: https://python3-trepan.readthedocs.org/en/latest/commands/running/step.html\n.. _subst: https://python3-trepan.readthedocs.io/en/latest/commands/set/substitute.html\n.. _install: https://python3-trepan.readthedocs.org/en/latest/install.html\n.. |Supported Python Versions| image:: https://img.shields.io/pypi/pyversions/trepan3k.svg\n   :target: https://pypi.python.org/pypi/trepan3k/\n.. |Pypi Installs| image:: https://pepy.tech/badge/trepan3k\n.. |packagestatus| image:: https://repology.org/badge/vertical-allrepos/python:trepan3k.svg\n\t\t :target: https://repology.org/project/python:trepan3k/versions\n.. |docs| image:: https://readthedocs.org/projects/python3-trepan/badge/?version=latest\n    :target: https://python3-trepan.readthedocs.io/en/latest/?badge=latest\n    :alt: Documentation Status\n\n",
    "bugtrack_url": null,
    "license": "GPL3",
    "summary": "GDB-like Python Debugger in the Trepan family",
    "version": "1.3.0",
    "project_urls": {
        "Homepage": "http://github.com/rocky/python3-trepan/"
    },
    "split_keywords": [],
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "blake2b_256": "c9bdd3418488aeb8e36a29f51d237abd2d1e689a1e47b6492181d76625f905f7",
                "md5": "653ef15c9647f6ea58af86372207621b",
                "sha256": "01849d678284b6c1ae7e1fae34991ebb0e96999490a5577314058d29823eb9f7"
            },
            "downloads": -1,
            "filename": "trepan3k-1.3.0-310-none-any.whl",
            "has_sig": false,
            "md5_digest": "653ef15c9647f6ea58af86372207621b",
            "packagetype": "bdist_wheel",
            "python_version": "310",
            "requires_python": null,
            "size": 379409,
            "upload_time": "2024-11-13T15:52:30",
            "upload_time_iso_8601": "2024-11-13T15:52:30.279291Z",
            "url": "https://files.pythonhosted.org/packages/c9/bd/d3418488aeb8e36a29f51d237abd2d1e689a1e47b6492181d76625f905f7/trepan3k-1.3.0-310-none-any.whl",
            "yanked": false,
            "yanked_reason": null
        },
        {
            "comment_text": "",
            "digests": {
                "blake2b_256": "7aa07f30fd112c6ff10cd02d4ec995586ccb674e910723813469f18c01363bf0",
                "md5": "3504fde8385f5f707660d5427bf2b8c8",
                "sha256": "170b86ec7f8ea7da2f91a6fe0dc99e27b671ad56b8e4efd52cbc564de889ccde"
            },
            "downloads": -1,
            "filename": "trepan3k-1.3.0-35-none-any.whl",
            "has_sig": false,
            "md5_digest": "3504fde8385f5f707660d5427bf2b8c8",
            "packagetype": "bdist_wheel",
            "python_version": "35",
            "requires_python": null,
            "size": 409291,
            "upload_time": "2024-11-13T15:53:21",
            "upload_time_iso_8601": "2024-11-13T15:53:21.228516Z",
            "url": "https://files.pythonhosted.org/packages/7a/a0/7f30fd112c6ff10cd02d4ec995586ccb674e910723813469f18c01363bf0/trepan3k-1.3.0-35-none-any.whl",
            "yanked": false,
            "yanked_reason": null
        },
        {
            "comment_text": "",
            "digests": {
                "blake2b_256": "ef38f13f22647d5021b06ad38e0fa612cd3a5d2e387dfcad4e80ba0018c0794d",
                "md5": "2a5762aafa6f241759744d40d9c50cee",
                "sha256": "68bd68cec6552b6e097f174b0b27cd9b66360f2643a64856741f26519708783e"
            },
            "downloads": -1,
            "filename": "trepan3k-1.3.0-36-none-any.whl",
            "has_sig": false,
            "md5_digest": "2a5762aafa6f241759744d40d9c50cee",
            "packagetype": "bdist_wheel",
            "python_version": "36",
            "requires_python": null,
            "size": 379434,
            "upload_time": "2024-11-13T15:53:23",
            "upload_time_iso_8601": "2024-11-13T15:53:23.760601Z",
            "url": "https://files.pythonhosted.org/packages/ef/38/f13f22647d5021b06ad38e0fa612cd3a5d2e387dfcad4e80ba0018c0794d/trepan3k-1.3.0-36-none-any.whl",
            "yanked": false,
            "yanked_reason": null
        },
        {
            "comment_text": "",
            "digests": {
                "blake2b_256": "7af7b8d14cb6c24817eb6788b362e64e950a980d78fe2e5cbb3cdc299dcfeef0",
                "md5": "0a331f5700b09e8ee4dcf76afbda4071",
                "sha256": "be6893ab890b479861b2307210857d28fb12f22b5826838e8f7bae3e48a11e75"
            },
            "downloads": -1,
            "filename": "trepan3k-1.3.0-37-none-any.whl",
            "has_sig": false,
            "md5_digest": "0a331f5700b09e8ee4dcf76afbda4071",
            "packagetype": "bdist_wheel",
            "python_version": "37",
            "requires_python": null,
            "size": 379411,
            "upload_time": "2024-11-13T15:53:24",
            "upload_time_iso_8601": "2024-11-13T15:53:24.952128Z",
            "url": "https://files.pythonhosted.org/packages/7a/f7/b8d14cb6c24817eb6788b362e64e950a980d78fe2e5cbb3cdc299dcfeef0/trepan3k-1.3.0-37-none-any.whl",
            "yanked": false,
            "yanked_reason": null
        },
        {
            "comment_text": "",
            "digests": {
                "blake2b_256": "4511a9bd38e5b3c076747ff9ed831fee0402c4ba023565d4440d5a31c39f63ea",
                "md5": "bdef4c55b41af373658c1a731c3995a8",
                "sha256": "11327d37d0008f50066210a2d2ead0b81e70969285f27144749356f4bf5cca0f"
            },
            "downloads": -1,
            "filename": "trepan3k-1.3.0-38-none-any.whl",
            "has_sig": false,
            "md5_digest": "bdef4c55b41af373658c1a731c3995a8",
            "packagetype": "bdist_wheel",
            "python_version": "38",
            "requires_python": null,
            "size": 379404,
            "upload_time": "2024-11-13T15:53:26",
            "upload_time_iso_8601": "2024-11-13T15:53:26.122552Z",
            "url": "https://files.pythonhosted.org/packages/45/11/a9bd38e5b3c076747ff9ed831fee0402c4ba023565d4440d5a31c39f63ea/trepan3k-1.3.0-38-none-any.whl",
            "yanked": false,
            "yanked_reason": null
        },
        {
            "comment_text": "",
            "digests": {
                "blake2b_256": "80062732f5c7212040aee146a7c32c6ca50f500f2c33da278afe9937d9854f9c",
                "md5": "97f29955bef16ac20232eadf633e032e",
                "sha256": "39a4705faeffb4fb692a2e191507ce2a52f855a1a63cdc37cad3166f50a9b5f7"
            },
            "downloads": -1,
            "filename": "trepan3k-1.3.0-39-none-any.whl",
            "has_sig": false,
            "md5_digest": "97f29955bef16ac20232eadf633e032e",
            "packagetype": "bdist_wheel",
            "python_version": "39",
            "requires_python": null,
            "size": 379425,
            "upload_time": "2024-11-13T15:53:28",
            "upload_time_iso_8601": "2024-11-13T15:53:28.078383Z",
            "url": "https://files.pythonhosted.org/packages/80/06/2732f5c7212040aee146a7c32c6ca50f500f2c33da278afe9937d9854f9c/trepan3k-1.3.0-39-none-any.whl",
            "yanked": false,
            "yanked_reason": null
        },
        {
            "comment_text": "",
            "digests": {
                "blake2b_256": "73601651c4226a51da289490ae6177605972a9b62575ae8a4c59635e796049cd",
                "md5": "c2e0785402231f8fc939de1f078020cb",
                "sha256": "c03678ea699af5954a71ffb8d978244684f8ada1219e2bf2e42365fcc9c56fd9"
            },
            "downloads": -1,
            "filename": "trepan3k-1.3.0-py3-none-any.whl",
            "has_sig": false,
            "md5_digest": "c2e0785402231f8fc939de1f078020cb",
            "packagetype": "bdist_wheel",
            "python_version": "py3",
            "requires_python": null,
            "size": 579920,
            "upload_time": "2024-11-13T15:53:29",
            "upload_time_iso_8601": "2024-11-13T15:53:29.242893Z",
            "url": "https://files.pythonhosted.org/packages/73/60/1651c4226a51da289490ae6177605972a9b62575ae8a4c59635e796049cd/trepan3k-1.3.0-py3-none-any.whl",
            "yanked": false,
            "yanked_reason": null
        },
        {
            "comment_text": "",
            "digests": {
                "blake2b_256": "a49ee7018176cec5b3994c180b30665774c5fec2d560d30b8633de3f54a5a69b",
                "md5": "60d6fd596d6051c0248b27219d217ffe",
                "sha256": "e4e7ea48ac7a56b163e7f8e8378d1f1c995ed50d63b81235a57ec77fd31fea7b"
            },
            "downloads": -1,
            "filename": "trepan3k-1.3.0.tar.gz",
            "has_sig": false,
            "md5_digest": "60d6fd596d6051c0248b27219d217ffe",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": null,
            "size": 421097,
            "upload_time": "2024-11-13T15:53:30",
            "upload_time_iso_8601": "2024-11-13T15:53:30.546522Z",
            "url": "https://files.pythonhosted.org/packages/a4/9e/e7018176cec5b3994c180b30665774c5fec2d560d30b8633de3f54a5a69b/trepan3k-1.3.0.tar.gz",
            "yanked": false,
            "yanked_reason": null
        }
    ],
    "upload_time": "2024-11-13 15:53:30",
    "github": true,
    "gitlab": false,
    "bitbucket": false,
    "codeberg": false,
    "github_user": "rocky",
    "github_project": "python3-trepan",
    "travis_ci": true,
    "coveralls": true,
    "github_actions": true,
    "circle": true,
    "appveyor": true,
    "requirements": [
        {
            "name": "columnize",
            "specs": [
                [
                    ">=",
                    "0.3.10"
                ]
            ]
        }
    ],
    "tox": true,
    "lcname": "trepan3k"
}

Rocky Bernstein