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
|
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
|
||||||
==============
|
==============
|
||||||
|
|
Loading…
Reference in New Issue