A few more open issues, and use subheaders for each.
This commit is contained in:
parent
134ce1253b
commit
728dd46ff2
22
pep-0553.rst
22
pep-0553.rst
|
@ -82,10 +82,16 @@ returns whatever is returned from the underlying debugger entry point.
|
|||
Open issues
|
||||
===========
|
||||
|
||||
Confirmation from other debugger vendors
|
||||
----------------------------------------
|
||||
|
||||
We want to get confirmation from at least one alternative debugger
|
||||
implementation (e.g. PyCharm) that the hooks provided in this PEP will
|
||||
be useful to them.
|
||||
|
||||
Breakpoint bytecode
|
||||
-------------------
|
||||
|
||||
Related, there has been an idea to add a bytecode that calls
|
||||
``sys.breakpointhook()``. Whether built-in ``breakpoint()`` emits
|
||||
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
|
||||
this idea into a separate PEP.
|
||||
|
||||
Breakpoint arguments
|
||||
--------------------
|
||||
|
||||
Does it make sense to define the built-in function's signature as
|
||||
``breakpoint(*args, **kws)`` which would just be passed along to the
|
||||
``sys.breakpointhook()``? One argument for doing this is that it
|
||||
would allow users to pass useful arguments to their actual debugger.
|
||||
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
|
||||
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
|
||||
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
|
||||
==============
|
||||
|
|
Loading…
Reference in New Issue