This project has moved and is read-only. For the latest updates, please go here.

Accessing debugger context in Interactive window

May 24, 2012 at 5:54 PM

Hello, is it possible to stop a running program at a breakpoint, then go to the Interactive window to type in function calls, variable names, etc. of the debuggee?  No matter what context I choose in the pull-down at the top of the interactive window, I get an error saying that the variables I try to print are not defined.


May 24, 2012 at 7:30 PM

Not presently - that's the debug repl feature (, feel free to vote it up!

May 25, 2012 at 12:26 AM

Thanks dinov, I did vote for it.  Similarly, is there a way to edit a running app?  For example, 

def foo(x):
    print x

while 5 > 3:

I set a breakpoint at the foo(2) call, then while it is broken, I edit the line to say



But '2' is still printed even after that.  My change did not get 'compiled'.  I come from a C++ background and thought a main advantage of a dynamic language like Python is it let you interact with running apps like this?  What big thing am I missing?



May 25, 2012 at 5:14 PM

That would be edit and continue support.  We don't yet have that feature and we're not yet planning on doing it either...  It'll be very difficult and involve lots of crazy work to integrate w/ the underlying Python runtime.  I'd love to add it at some point, but the debug REPL will probably happen much sooner.

Jun 1, 2012 at 7:04 AM
Edited Jun 1, 2012 at 5:32 PM

OK, thanks.   Edit and Continue works with C++ and C#, but these have mostly broken debug repl.  (You can do a few things in the Immediate Window, though.)  

What I'm really looking for is an environment similar to 1980's style Instant-C and C-Terp that, while the program is running, you can break into a command console to do things like edit functions, compile them, and then have the running app call them immediately (Edit and Continue), as well as of course manually call functions from the command-line (and those functions take into account the state of the running app).

But what I'm hearing is the static languages like C++/C# have about as much debug support for this as dynamic languages like Python (and none of it is exactly what I'm looking for)... yet I keep hearing how much more productive Python is.  Why is that, please? 


Jun 3, 2012 at 4:52 AM

I think I remember doing edit and continue back in the days of VB3 (20 years ago?). It is a great productivity enhancer when prototyping new code. Unfortunately, I don't know of any scripting language that has edit and continue in VS, or any other IDE for that matter, unless you count VBA in office apps. I've looked around for such a thing for Javascript and found nothing. I would love to see it for Javascript or Python in Visual Studio. At this point, I'll take what I can get with Python, as long as I can use it in VS and don't have to deal with Eclipse!

FYI, I was experimenting and found this. It does not replace E&C, but it is interesting. If your current breakpoint is in, and you update, you can do this in the immediate window:

Your current state is retained and any functions in mod2 are updated. Unfortunately, I would probably be making all my changes in the current module, mod1, so I don't see this replacing true edit and continue for me.

Jun 4, 2012 at 7:47 AM

Edit and Continue basically requires the cooperation of the interpreter or compiler. VC can do it because the compiler has special support for recompiling individual functions and transferring the execution context - a lot of work went into this. Early versions of VB were interpreted languages (VB5 was the first to support native compilation, IIRC), making E&C even easier.

Unfortunately for us, we don't write the Python compilers/interpreter that PTVS supports. Supporting E&C in CPython probably requires intimate knowledge of its compiler and bytecode format, and the interpreter and its internal state. We would have to restrict support to only those exact versions we've implemented, since even compiling CPython with different compiler settings could invalidate the assumptions necessary to mess around within it. IronPython may be easier to support here, but that's pure speculation on my part. I do have a couple of ideas of how E&C could be done, possibly even in an interpreter-independent way, and I'm sure the team has discussed it internally, but any implementation would require huge amounts of work that we don't have the developers to support right now.