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.