A few more open issues, and use subheaders for each.

This commit is contained in:
Barry Warsaw 2017-09-06 17:16:32 -07:00
parent 134ce1253b
commit 728dd46ff2
1 changed files with 22 additions and 0 deletions

View File

@ -82,10 +82,16 @@ returns whatever is returned from the underlying debugger entry point.
Open issues Open issues
=========== ===========
Confirmation from other debugger vendors
----------------------------------------
We want to get confirmation from at least one alternative debugger We want to get confirmation from at least one alternative debugger
implementation (e.g. PyCharm) that the hooks provided in this PEP will implementation (e.g. PyCharm) that the hooks provided in this PEP will
be useful to them. be useful to them.
Breakpoint bytecode
-------------------
Related, there has been an idea to add a bytecode that calls Related, there has been an idea to add a bytecode that calls
``sys.breakpointhook()``. Whether built-in ``breakpoint()`` emits ``sys.breakpointhook()``. Whether built-in ``breakpoint()`` emits
this bytecode (or gets peephole optimized to the bytecode) is an open this bytecode (or gets peephole optimized to the bytecode) is an open
@ -95,12 +101,18 @@ bytecode streams to trampoline into their own debugger. Having a
in order to invoke this trampoline. *NOTE*: It probably makes sense to split in order to invoke this trampoline. *NOTE*: It probably makes sense to split
this idea into a separate PEP. this idea into a separate PEP.
Breakpoint arguments
--------------------
Does it make sense to define the built-in function's signature as Does it make sense to define the built-in function's signature as
``breakpoint(*args, **kws)`` which would just be passed along to the ``breakpoint(*args, **kws)`` which would just be passed along to the
``sys.breakpointhook()``? One argument for doing this is that it ``sys.breakpointhook()``? One argument for doing this is that it
would allow users to pass useful arguments to their actual debugger. would allow users to pass useful arguments to their actual debugger.
This isn't useful for ``pdb`` but might be useful for alternatives. This isn't useful for ``pdb`` but might be useful for alternatives.
Environment variable
--------------------
Should we add an environment variable so that ``sys.breakpointhook()`` can be Should we add an environment variable so that ``sys.breakpointhook()`` can be
set outside of the Python invocation? E.g.:: set outside of the Python invocation? E.g.::
@ -110,6 +122,16 @@ This would provide execution environments such as IDEs which run Python code
inside them, to set an internal breakpoint hook before any Python code inside them, to set an internal breakpoint hook before any Python code
executes. executes.
Call a fancier object by default
--------------------------------
Some folks want to be able to use other ``pdb`` interfaces such as
``pdb.pm()``. Although this is a less commonly used API, it could be
supported by binding ``sys.breakpointhook`` to an object that implements
``__call__()``. Calling this object would call ``pdb.set_trace()``, but the
object could expose other methods, such as ``pdb.pm()``, making invocation of
it as handy as ``breakpoint.pm()``.
Implementation Implementation
============== ==============