Breakpoint conditions and ignore counts

 PyScripter has always supported conditional breakpoints.   Conditional breakpoints allow you to finetune the debugging experience, by only stopping execution when certain conditions are met.

Consider the following example:

def main():

    sum = 0

    for i in range(1000):

        sum = sum + i

    print(sum)

if __name__ == '__main__':

    main()

Say you are interested to know when sum becomes >= 1000.  If you set a breakpoint at the 4th line of the code, it will be tedious and time consuming to reach that point.   What you can do is to set a conditional breakpoint:

When you debug the code, execution will stop at the break point only when the condition is met (i = 46).

As you can tell from the screenshot above, the forthcoming version of PyScripter, introduces and new breakpoint property "Ignore Count".  If you set the the Ignore Count to a positive integer value, then the breakpoint will be ignored a number of times equal to that value.  So in the above example if you remove the condition and set the Ignore Count to 100, execution will stop when i becomes 100.  When you resume execution, the breakpoint will be ignored another 100 times.

There are a few ways to set the breakpoint properties Condition and Ignore Count.

• In the Breakpoints Window select the property you want to change and press F2.  This will allow you to edit the property directly.  Press Enter when you are done:

• In the Breakpoints Window right-click on the breakpoint and select "Breakpoint Properties...".  A dialog box like the following pops up and you can edit the values.

• In the editor, when you click on a breakpoint you get a context menu (new feature) from which you can select "Breakpoint Properties..."

Another breakpoint tip:

• You can quickly disable/enable a breakpoint by Ctrl + clicking on it in the editor gutter.

Teaser: Super fast debugging is coming to PyScripter

 You expect code to run with debugging much slower than without.  Indeed this is the case and with python, debugging can be sometimes painfully slow.  

A relatively recent, low-level feature that was introduces in Python 3.12 is monitoring. Monitoring allows programmers to hook into low level events that occur during the execution of code.   This is similar to tracing, which is used by debuggers, but with much greater granularity and control.  It turns out that monitoring can help make faster debuggers.  Much faster.  The next version of PyScripter will include a new debugger that is based on monitoring for python versions 3.12+.  Just to give you a taste of the speed-up you get, consider the following code:

import time

def test():

    start_time = time.time()

    for i in range(1000):

        for j in range(1000):

            j + i

    cost = time.time() - start_time

    print("Elapsed time: ", cost)

    f(0)

def f(x):

    # Set breakpoint here

    x *= 2

    return x + 1

test()

If you set a break point at the line "f(0)" and start debugging, this is what you get with the PyScripter v5.1.4 and python 3.13. 

*** Remote Interpreter Reinitialized ***

Elapsed time:  2.5882363319396973

[Dbg]>>> 

There are a million iterations that happen before you reach the breakpoint, so this takes about 2.5 seconds. If you do the same with the forthcoming release of PyScripter you get:

*** Remote Interpreter Reinitialized ***

Elapsed time:  0.016160964965820312

[Dbg]>>> 

This is more than x150 speed-up.  The code until you reach the breakpoint, runs almost as fast as without debugging.  The new debugger shines when you debug over loops or other pieces of code that it is executed repetitively.  For other types of code the speedup is not as impressive.

The new release also back-ports some debugging improvements introduced in python 3.14 to python versions 3.10+.   So users of these versions will experience faster debugging.

PyScripter v5.1.3 released

PyScripter v5.1.3 is now available at Sourceforge. Despite being a minor release it does include a number of new features and improvements:

• Support for Python 3.14
• Support for free-threaded python
• New external tool "Create venv"
• Support tqdm and similar modules in the interactive interpreter (#812)
• The Chat Window renders Markdown
• The Assistant can use a greater variety of Ollama models
• Layouts now include the secondary workspace status (#494)