[Python-Dev] PEP 553

[Glenn Linderman]

On 10/4/2017 5:22 PM, Yarko Tymciurak wrote:
> Barry suggested I bring this up here.
>
> It seems the right time to at least discuss this:
>
> RE:  PEP 553 enabling / disabling breakpoints ---
>
> I've recently started using a simple conditional breakpoint in 
> ipython, and wonder if  - in addition to Nick Coghlan's request for 
> the env 'PYTHONBREAKPOINT'  (boolean?), it would make sense (I _think_ 
> so) to add a condition parameter to the breakpoint() call.  This does 
> raise several questions, but it seems that it could make for a simple 
> unified way to conditionally call an arbitrary debugger.  What I found 
> useful (in the contecxt of ipython - but general enough) you can see 
> in this gist: 
> https://gist.github.com/yarko/bdaa9d3178a6db03e160fdbabb3a9885
>
> If PEP 553's breakpoint() were to follow this sort of interface (with 
> "condition"), it raises a couple of questions:
> - how would a missing (default) parameter be done?
> - how would parameters to be passed to the debugger "of record" be 
> passed in (named tuple? - sort of ugly)
> - would PYTHONBREAKPOINT be a global switch (I think yes), vs a 
> `condition` default.
>
> I have no dog in the fight, but to raise the possibility (?) of having 
> PEP 553 implement simple conditional breakpoint processing.
>
> Any / all comments much appreciated.
>
breakpoint() already accepts arguments. Therefore no change to the PEP 
is needed to implement your suggestion. What you are suggesting is 
simply a convention among debuggers to handle a parameter named 
"condition" in a particular manner.

It seems to me that

if condition:
     breakpoint()

would be faster and clearer, but there is nothing to prevent a debugger 
from implementing your suggestion if it seems useful to the developers 
of the debugger. If it is useful enough to enough people, the users will 
clamor for other debuggers to implement it also.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171004/0a2a714e/attachment.html>