@Fischer: Your link has absolutely nothing to do with what xterm is talking about.

You shared a link to one of the (oh so numerous) online Python courses, when xterm is showing a "teaching tool" that helps tutors step through the execution of a code while explaining it to their student. What you share is boring, common and frankly not worth talking about (although I have read more than a few lessons by Nick Parlante - the author of the course - and I can attest he has a great teaching style).

What xterm shares is much more novel and exciting. I just think that until they publish the instructions on how to embed it in our own software (Lebgeeks?) it's more hype than it is value.
I played with the tool. Much like any good thing, it takes some time getting used to.

The first problem I found is that it limits the number of execution steps to 300 (to avoid the problem of infinite loops).

I don't see what the problem with infinite loops is. I'd expect a debugger (because this is what it is, a glorified - but limited- debugger) to let me step through the execution of my code, regardless of the total number of steps.

That being said, if implementation limitations prevent the tool from dealing with infinite numbers of steps, I would like a way to increase/decrease the 300 limit.
rahmu wroteI don't see what the problem with infinite loops is. I'd expect a debugger (because this is what it is, a glorified - but limited- debugger) to let me step through the execution of my code, regardless of the total number of steps.
Here's the problem as I see it with infinite loops. I placed some thought into what it takes to build such a thing and the picture became clearly the more I thought about how 'I' would approach building such a thing.

So I'll make an assumption as to how this works:

1- User enters python code (C).
2- C gets sent to the server one time only.
3- The server executes C in the python debugger (PDB).
4- The debugger runs once until end and generates all the corresponding steps alongside a memory dump of the variables in each step (GS).
5- GS get sent back to the client that uses Javascript to render the result in a 'step by step' manner, also rendering the data as shown in pythontutor.

Notice that there's only a one time communication between the client and the server since all python tutor needs is a one off run of PDB. Hence allowing infinite loops will not be possible without back and forth communication between the client and the server, not to mention keeping a PDB instance running for each C that's currently being loaded.
That being said, if implementation limitations prevent the tool from dealing with infinite numbers of steps, I would like a way to increase/decrease the 300 limit.
That could be an option yes.

-

This would be a fun small project to do by the way! It wouldn't take much to have a proof of concept.