debugging in eclipse

[chip...@gmail.com]

Hi all!

I have a stupid problem, for which I cannot find a solution...

I have a python module, lets call it debugTest.py.

and it contains:
def test():
a=1
b=2
c=a+b
c

so as simple as possible.

Now I would like to debug it in eclipse.. (I have pydev and all)
so the question is how do I debug the test function? (by debug I mean go into it in the debugging mode and execute step by step, inspect the variables and so on.. you know, like it is so easily done in Matlab for example).

I place a break point in the function, run the debugger and it stars and is terminated immediately. (of course it does not know where to go..)

So how can I do this? please help!

Thank you all in advance!

[Roy Smith]

In article <b45840eb-f429-4287...@googlegroups.com>,

chip...@gmail.com wrote:

> Now I would like to debug it in eclipse..

Heh. It took me a while to realize that the subject line was not
referring to
http://en.wikipedia.org/wiki/Solar_eclipse_of_November_13,_2012

[Dave Angel]

On 11/15/2012 07:29 AM, chip...@gmail.com wrote:
> Hi all!
>
> I have a stupid problem, for which I cannot find a solution...
>
> I have a python module, lets call it debugTest.py.
>
> and it contains:
> def test():
> a=1
> b=2
> c=a+b
> c
>
> so as simple as possible.
>
> Now I would like to debug it in eclipse.. (I have pydev and all)
> so the question is how do I debug the test function? (by debug I mean go into it in the debugging mode and execute step by step, inspect the variables and so on.. you know, like it is so easily done in Matlab for example).
>

I don't know Eclipse, but you probably have to have some top-level code
in your program. As it stands, it's just an importable module, doing
nothing useful when you run it.

Add a call to test() to the end of the file, and it might do better.
I'd also add a print statement, just to assure yourself that it's running.

--

DaveA

[chip...@gmail.com]

On Thursday, November 15, 2012 1:49:22 PM UTC+1, Roy Smith wrote:
> Heh. It took me a while to realize that the subject line was not
> referring to
> http://en.wikipedia.org/wiki/Solar_eclipse_of_November_13,_2012

:))

[Martin P. Hellwig]

I assume you have at the end of the debugTest.py file something like this:

if __name__ == '__main__':
test()

[chip...@gmail.com]

On Thursday, November 15, 2012 2:42:09 PM UTC+1, Dave Angel wrote:
> Add a call to test() to the end of the file, and it might do better.
>
> I'd also add a print statement, just to assure yourself that it's running.
>
>

thanks, that is it, (stupid me) now if I have many functions in the model I will simply ad a call to the specific function at the end and that is it...

working on the project too long, all the simple and smart ideas are long gone ;)

thanks!

[chip...@gmail.com]

On Thursday, November 15, 2012 2:42:09 PM UTC+1, Dave Angel wrote:

> Add a call to test() to the end of the file, and it might do better.
>
> I'd also add a print statement, just to assure yourself that it's running.
>
>

[chip...@gmail.com]

On Thursday, November 15, 2012 2:44:22 PM UTC+1, Martin P. Hellwig wrote:
> I assume you have at the end of the debugTest.py file something like this:
> if __name__ == '__main__':
> test()

no i did not have it...

is main really necessary?

[Roy Smith]

In article <mailman.3714.1352986...@python.org>,

Dave Angel <d...@davea.name> wrote:

> I'd also add a print statement, just to assure yourself that it's running.

My trick to make sure something is running is to add "assert 0".

To be fair, I usually start by adding a print statement, as Dave
suggests. If I see the output, I know it ran. But if I don't see the
output, there's two possibilities. Either it didn't run, or it ran but
something snarfed the output and hid it from my eyes. That's common in
test frameworks. It's also common in background processes where stdout
goes who-knows-where, and it's anybody's guess how the logging config
might be borked.

On the other hand, an "assert 0" is pretty much guaranteed to produce
some visible evidence that it ran. About the only thing that would stop
it is if somebody had wrapped the code in a try block which caught
AssertionError (or Exception).

[Ulrich Eckhardt]

Am 15.11.2012 13:29, schrieb chip...@gmail.com:
> I have a python module, lets call it debugTest.py.
>
> and it contains:
> def test():
> a=1
> b=2
> c=a+b
> c
>
> so as simple as possible.

Should that be "return c" instead of "c" on a line?

> Now I would like to debug it in eclipse.. (I have pydev and all) so
> the question is how do I debug the test function?

[...]

> I place a break point in the function, run the debugger and it stars
> and is terminated immediately.

For a start, I would try to actually call the function. Just add
"print(test())" after the function definition.

Uli

[Alister]

doing it that way means that it will only call test when executed
directly & not when imported as a module



--
I used to be an agnostic, but now I'm not so sure.

[chip...@gmail.com]

On Thursday, November 15, 2012 2:43:26 PM UTC+1, Ulrich Eckhardt wrote:
> Should that be "return c" instead of "c" on a line?

oh it is just a silly example function, the functionality is not important. It does not have to return anything...

> For a start, I would try to actually call the function. Just add
> "print(test())" after the function definition.

yes I call the function now, that was the thing...

[chip...@gmail.com]

On Thursday, November 15, 2012 3:21:52 PM UTC+1, Alister wrote:
> doing it that way means that it will only call test when executed
> directly & not when imported as a module

I see, thanks!

[Aahz]

In article <roy-F45720.0...@news.panix.com>,

Roy Smith <r...@panix.com> wrote:
>In article <mailman.3714.1352986...@python.org>,
> Dave Angel <d...@davea.name> wrote:
>>
>> I'd also add a print statement, just to assure yourself that it's running.
>
>My trick to make sure something is running is to add "assert 0".

``1/0`` is shorter. ;-)
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

"LL YR VWL R BLNG T S" -- www.nancybuttons.com

[Steven D'Aprano]

On Thu, 15 Nov 2012 07:56:17 -0800, Aahz wrote:

> In article <roy-F45720.0...@news.panix.com>, Roy Smith
> <r...@panix.com> wrote:
>>In article <mailman.3714.1352986...@python.org>,
>> Dave Angel <d...@davea.name> wrote:
>>>
>>> I'd also add a print statement, just to assure yourself that it's
>>> running.
>>
>>My trick to make sure something is running is to add "assert 0".
>
> ``1/0`` is shorter. ;-)

It is also guaranteed to run, unlike assert.



--
Steven

[alex23]

On Nov 16, 3:05 am, Steven D'Aprano <steve

+comp.lang.pyt...@pearwood.info> wrote:
> > ``1/0`` is shorter.  ;-)
>
> It is also guaranteed to run, unlike assert.

Only if they actively pass the command line switch to turn it off,
which I'd assume someone intentionally using an assertion wouldn't do.

[Steven D'Aprano]

On Thu, 15 Nov 2012 17:10:27 -0800, alex23 wrote:

> On Nov 16, 3:05 am, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:
>> > ``1/0`` is shorter.  ;-)
>>
>> It is also guaranteed to run, unlike assert.
>
> Only if they actively pass the command line switch to turn it off,

Not necessarily "actively".

On Linux you can set up command aliases, e.g. `alias python=python -O`
and I dare say there is some equivalent under Windows. Once you have done
so (which could be many months in the past, and forgotten about) you no
longer need to actively specify -O to run with optimization on.

> which
> I'd assume someone intentionally using an assertion wouldn't do.

Provided that they know the side-effect of -O, and that the code contains
an assertion.

Not all code is executed by the same person who wrote it, and not all
people remember every fine detail about every script they wrote. I
couldn't possibly tell you what all my scripts do without checking the
source code.



--
Steven