Can I debug an expression?

Jan 27, 2013 at 9:35 PM

Hi!

It seems to me that the natural way to debug python code isn't to run "a project" but to execute an expression. However, breakpoints in my code don't seem to be hit whether an expression is evaluated in a normal interactive window or the debug interactive and I can't find any explicit mention of such a feature.

Can it be done?

Johan

Coordinator
Jan 28, 2013 at 3:31 PM

It can be done by going into the Options dialog, selecting "Python Tools" and "Interactive Windows", choosing the interpreter you're using, and selecting "Enable attaching to interactive window". Once you've done this, you can type "$attach" in the window and the debugger will start. You should now be able to place breakpoints in any files that you are calling into. The "Stop Debugging" button (a red square) will disconnect the debugger.

The reason we don't have this enabled by default is that the debugger reduces performance, typically not by much, but often enough to interfere with people using the interactive windows for non-debugging tasks.

I am interested in how you use Python, since you consider debugging at the expression level to be more natural. It sounds like a use scenario that we may not have considered. The project approach is influenced by Python's debugging support requiring the use of a script and Visual Studio's standard use of per-project settings rather than per-file, and while it's unlikely that we're going to make PTVS behave significantly different from other VS languages, we can certainly tweak aspects to make it better for those who don't want to use it that way.

Jan 28, 2013 at 7:26 PM
> It can be done by going into the Options dialog, selecting "Python Tools"
> and "Interactive Windows", choosing the interpreter you're using, and
> selecting "Enable attaching to interactive window". Once you've done this,
> you can type "$attach" in the window and the debugger will start.

Ah! So that's what that means! Thanks, that's all I need.

> The reason we don't have this enabled by default is that the debugger
> reduces performance, typically not by much, but often enough to interfere
> with people using the interactive windows for non-debugging tasks.

I think it's the correct decision that it's something you actively choose to do.

> I am interested in how you use Python, since you consider debugging at the
> expression level to be more natural. It sounds like a use scenario that we
> may not have considered.

I would say that the process is a lot like this. I start out with
playing around with some fragments of what I need to do either in a
file and then sending it to the interactive window or just playing
around in the REPL and then cut-and-pasting into a file. As I
progress, I refactor into functions and/or classes. Eventually, when
I'm almost done, I might add a main function and argparse a bit.

Let's say I have a shiny new function and I write a doctest for it
that fails. If it's not immediately obvious to me why it fails, I'd
like to set a breakpoint and check out how the state differs from what
I expected. It is then much easier to just make the call from the REPL
than scriptify a call to that function with the parameters I want to
debug. Why make the roundtrip to end up back where I started?

> The project approach is influenced by Python's
> debugging support requiring the use of a script

While I'm by no means claiming that pdb is a pleasant way to debug
things, pdb.run, pdb.runeval and pdb.runcall seems to be the obvious
counter-examples.

> and Visual Studio's standard
> use of per-project settings rather than per-file, and while it's unlikely
> that we're going to make PTVS behave significantly different from other VS
> languages, we can certainly tweak aspects to make it better for those who
> don't want to use it that way.

It's already such a tremendous improvement over what I was using
before that I'm more than happy with what is already there. That said,
this is one area that feels a little unpythonic to me.
Coordinator
Jan 28, 2013 at 7:41 PM

Glad to hear you're happy.

pdb's helper functions are certainly designed for use from an interactive prompt, which has not been a focus of PTVS. The interactive windows are a convenient feature, but not the main show, so to speak. That said, we're looking at making some significant changes to them for our next release, so we can take the opportunity to improve debugging here.

Feb 3 at 9:37 AM
This is an awesome feature. +1 on everything Troff said about the development process of scripting languages, they indeed differ from natural VS languages. This feature is very commonly used in MATLAB for example, and it really speeds up the development process. I think the main reason for the need of such feature in scripting language is because they are so much more high level, thus more prone to logical bugs. A function using pandas or numpy can express complexity of several hundreds if not thousands of C++/C# code. thus the need to immediately check your code is logically valid.

Way to go with this feature :)
Feb 4 at 1:56 PM
Hi,

Im trying to use the feature right now, but cant get it to work.
I typed $attach in the interactive window and indeed the debugger opened. but, I cant seem to launch project functions from the interactive window and stop at a break point set at the launched function. What is the proper why to do that?