Thomas Jollans writes:
> I just wanted to know what tools everyone used for debugging Python
> applications - scripts / backend / desktop apps / notebooks / whatever.
> Apart from the usual dance with log files and strategically inserted
> print() calls, that is.
>
> Of course we all know and mild
On 25/10/2017 15:08, Michele Simionato wrote:
pdb plus plus: https://pypi.python.org/pypi/pdbpp
I like the idea, but in putty at least changing the terminal size causes pdb++
to detach immediately from the process and mess up the screen. I think this is
caused by (5, 'Input/output error') here
-industrial
applications with tkinter and they have a nice factory-floor vibe.
I generally just use pdb for debugging. The feature I miss most is the
ability to trap to the debugger if the program throws an unhandled
exception. I think some other Python debuggers do support that. I've
foun
On 25/10/17 22:18, Terry Reedy wrote:
> On 10/25/2017 12:12 PM, Thomas Jollans wrote:
>> On 2017-10-25 15:57, Rustom Mody wrote:
>>>
>>> pdb inside emacs works (to a fashion)
>>> And it shows the arrow for current line so its at least quasi-gui
>>>
>>> I believe idle too is much more usable than a
W dniu 25.10.2017 o 15:53, Ned Batchelder pisze:
> On 10/25/17 9:07 AM, Thomas Jollans wrote:
>> Hi,
>>
>> I just wanted to know what tools everyone used for debugging Python
>> applications - scripts / backend / desktop apps / notebooks / whatever.
>> Apart from the usual dance with log files and
On 10/25/2017 12:12 PM, Thomas Jollans wrote:
On 2017-10-25 15:57, Rustom Mody wrote:
pdb inside emacs works (to a fashion)
And it shows the arrow for current line so its at least quasi-gui
I believe idle too is much more usable than a few years earlier
I haven't used IDLE in years (if ever)
Il 25/10/2017 15:07, Thomas Jollans ha scritto:
Hi,
I just wanted to know what tools everyone used for debugging Python
applications - scripts / backend / desktop apps / notebooks / whatever.
Apart from the usual dance with log files and strategically inserted
print() calls, that is.
Of course
On Wednesday, October 25, 2017 at 9:07:47 AM UTC-4, Thomas Jollans wrote:
> Hi,
>
> I just wanted to know what tools everyone used for debugging Python
> applications - scripts / backend / desktop apps / notebooks / whatever.
> Apart from the usual dance with log files and strategically inserted
>
On 2017-10-25 15:57, Rustom Mody wrote:
>
> pdb inside emacs works (to a fashion)
> And it shows the arrow for current line so its at least quasi-gui
>
> I believe idle too is much more usable than a few years earlier
I haven't used IDLE in years (if ever), partly because Tkinter is so
incredibl
> On Oct 25, 2017, at 9:07 AM, Thomas Jollans wrote:
>
>
[byte]
> What options are there for Python (that work)? What text editors (and
> IDEs) have a decent integrated debugger or debugging plugin?
I rather like WingIDE (the name is a coincidence). It allows insertion/removal
of break poi
Fabien wrote:
On 10/25/2017 03:07 PM, Thomas Jollans wrote:
What options are there for Python (that work)?
PyCharm's debugger is fine (also available in the community edition)
+1
Cheers,
Fabien
--
https://mail.python.org/mailman/listinfo/python-list
pdb plus plus: https://pypi.python.org/pypi/pdbpp
--
https://mail.python.org/mailman/listinfo/python-list
On 10/25/17 9:07 AM, Thomas Jollans wrote:
Hi,
I just wanted to know what tools everyone used for debugging Python
applications - scripts / backend / desktop apps / notebooks / whatever.
Apart from the usual dance with log files and strategically inserted
print() calls, that is.
Of course we al
On Wednesday, October 25, 2017 at 6:37:47 PM UTC+5:30, Thomas Jollans wrote:
> Hi,
>
> I just wanted to know what tools everyone used for debugging Python
> applications - scripts / backend / desktop apps / notebooks / whatever.
> Apart from the usual dance with log files and strategically inserte
On 10/25/2017 03:07 PM, Thomas Jollans wrote:
What options are there for Python (that work)?
PyCharm's debugger is fine (also available in the community edition)
Cheers,
Fabien
--
https://mail.python.org/mailman/listinfo/python-list
Hi,
I just wanted to know what tools everyone used for debugging Python
applications - scripts / backend / desktop apps / notebooks / whatever.
Apart from the usual dance with log files and strategically inserted
print() calls, that is.
Of course we all know and mildly dislike pdb.
Personally, i
On Wed, May 12, 2010 at 2:42 PM, Joel Koltner
wrote:
> Just curious... in Microsoft's Visual Studio (and I would presume some other
> tools), for many languages (both interpreted and compiled!) there's an "edit
> and conitnue" option that, when you hit a breakpoint, allows you to modify a
> line o
In message , Joel
Koltner wrote:
> Just curious... in Microsoft's Visual Studio (and I would presume some
> other tools), for many languages (both interpreted and compiled!) there's
> an "edit and conitnue" option that, when you hit a breakpoint, allows you
> to modify a line of code before it's
On 2010-05-13 00:07, Joel Koltner wrote:
Hey, a lot of people would argue that Python's lack of strong typing and
data/member protection (from one class to another) encourages sloppy
programming too. :-)
You're being ironic, aren't you?
Python does have strong typing (many people confuse tha
Cheap Chanel Watches for sale at: http://www.luxuryowner.net/
Chanel Watches collection:
http://www.luxuryowner.net/replica-chanel-watches.html
Chanel J12 Automatic Watches:
http://www.luxuryowner.net/Chanel-J12-Automatic-Watches.html
Chanel J12 Quartz Watches:
http://www.luxuryowner.net/Chan
On May 12, 3:03 pm, "Joel Koltner"
wrote:
> Pretty much, yeah... Realistically, we're probably talking less than a minute
> each time, so objectively it's not really a big deal -- it's just different
> than what I'm used to so I'm noticing it more. :-)
>
> I guess what I'm realizing here is that
"John Nagle" wrote in message
news:4beb15c5$0$1634$742ec...@news.sonic.net...
Having actually used LISP systems with "edit and continue", it's a good
thing that Python doesn't have it. It encourages a "patch" mentality, and
the resulting code is usually disappointing.
Hey, a lot of people
"Phlip" wrote in message
news:c014ae9f-99d8-4857-a3f7-e6ac16e45...@e34g2000pra.googlegroups.com...
Are you implying, after an edit, you need to start a program again,
then enter several user inputs, to navigate back to the place where
you hit the syntax error? (WxWidgets noted - props!)
Pretty
maybe ipython?
http://showmedo.com/videos/video?name=120&fromSeriesID=100
> From: zapwiredashgro...@yahoo.com
> Subject: Do any debuggers support "edit and continue?"
> Date: Wed, 12 May 2010 10:42:31 -0700
> To: python-list@python.org
>
> Just curious
Joel Koltner wrote:
Just curious... in Microsoft's Visual Studio (and I would presume some
other tools), for many languages (both interpreted and compiled!)
there's an "edit and conitnue" option that, when you hit a breakpoint,
allows you to modify a line of code before it's actually executed.
On May 12, 1:38 pm, "Joel Koltner"
wrote:
> Well, sure, that is the current fix... but an "edit and continue" feature
> would make for a much faster fix. :-)
Are you implying, after an edit, you need to start a program again,
then enter several user inputs, to navigate back to the place where
yo
"Phlip" wrote in message
news:75c050d2-365e-4b08-8716-884ed5473...@k25g2000prh.googlegroups.com...
On May 12, 12:44 pm, "Joel Koltner"
wrote:
Are you implying that you then run the code, and - after a handful of
higher-level calls - control flow gets down to the lines you just
typed, and the r
On May 12, 12:44 pm, "Joel Koltner"
wrote:
> I find myself making mistakes in typing the name of classes and/or methods
> when I'm first getting started with them (there are some thousands of them
> after all, and even of commonly used classes/methods you're probably talking
> upwards of a hundre
"Phlip" wrote in message
news:d580dece-bd42-4753-a0c6-783ce69b5...@m31g2000pre.googlegroups.com...
People who need "edit and continue" probably need developer tests
instead. You typically edit the test a little, run all the code, edit
the code a little, run all the code, and integrate whenever t
On May 12, 10:42 am, "Joel Koltner"
wrote:
> Does any Python debugger support this feature?
I have worked for >3 years by now in Python and have never once
debugged.
People who need "edit and continue" probably need developer tests
instead. You typically edit the test a little, run all the code
On 05/13/10 03:42, Joel Koltner wrote:
> Just curious... in Microsoft's Visual Studio (and I would presume some
> other tools), for many languages (both interpreted and compiled!)
> there's an "edit and conitnue" option that, when you hit a breakpoint,
> allows you to modify a line of code before i
I can see this being challenging. I think it's pretty cool how some
Python debuggers will allow you to use a shell with the context set to the
current function or any of the calling functions higher up the call stack
hierarchy as well.
This would also slow normal execution, so it would have to b
On 5/12/2010 1:42 PM, Joel Koltner wrote:
Just curious... in Microsoft's Visual Studio (and I would presume some
other tools), for many languages (both interpreted and compiled!)
there's an "edit and conitnue" option that, when you hit a breakpoint,
allows you to modify a line of code before it's
On 12-05-2010 19:42, Joel Koltner wrote:
> Just curious... in Microsoft's Visual Studio (and I would presume some
> other tools), for many languages (both interpreted and compiled!)
> there's an "edit and conitnue" option that, when you hit a breakpoint,
> allows you to modify a line of code before
)
but it is not working, bug??
Sandy
> From: zapwiredashgro...@yahoo.com
> Subject: Do any debuggers support "edit and continue?"
> Date: Wed, 12 May 2010 10:42:31 -0700
> To: python-list@python.org
>
> Just curious... in Microsoft's Visual Studio (and I would
Just curious... in Microsoft's Visual Studio (and I would presume some other
tools), for many languages (both interpreted and compiled!) there's an "edit
and conitnue" option that, when you hit a breakpoint, allows you to modify a
line of code before it's actually executed.
Does any Python deb
On Thu, May 6, 2010 at 5:59 AM, Sarah Mount wrote:
> On 5 May 2010 10:17, Carl Banks wrote:
>> On May 2, 11:06 am, Sarah Mount wrote:
>>> This is a bit of an odd question, but is there any way for a Python
>>> debugger to suppress I/O generated by the program which is being
>>> debugged? I guess
On 5 May 2010 10:17, Carl Banks wrote:
> On May 2, 11:06 am, Sarah Mount wrote:
>> This is a bit of an odd question, but is there any way for a Python
>> debugger to suppress I/O generated by the program which is being
>> debugged? I guess an "obvious" thing to do would be to replace core
>> part
On May 2, 11:06 am, Sarah Mount wrote:
> This is a bit of an odd question, but is there any way for a Python
> debugger to suppress I/O generated by the program which is being
> debugged? I guess an "obvious" thing to do would be to replace core
> parts of the standard library and change any relev
This is a bit of an odd question, but is there any way for a Python
debugger to suppress I/O generated by the program which is being
debugged? I guess an "obvious" thing to do would be to replace core
parts of the standard library and change any relevant imports in the
locals and globals dicts to f
Having some trouble getting rpdb2 and winpdb running properly with
Python embedded in a C++ project.
Our implementation has a number of C++ classes associated with Python
classes.
I am able to attach to the embedded script with the debugger and the
program freezes and waits. However, when I step
TheSaint <[EMAIL PROTECTED]> writes:
> On 19:21, venerdì 13 giugno 2008 R. Bernstein wrote:
>
>> I'm not completely sure what you mean, but I gather that in
>> post-mortem debugging you'd like to inspect local variables defined at the
>> place of error.
>
> Yes, exactly. This can be seen with pdb,
On 19:21, venerdì 13 giugno 2008 R. Bernstein wrote:
> I'm not completely sure what you mean, but I gather that in
> post-mortem debugging you'd like to inspect local variables defined at the
> place of error.
Yes, exactly. This can be seen with pdb, but not pydb.
If I'm testing a piece of code a
TheSaint <[EMAIL PROTECTED]> writes:
> Hi,
>
> while testing my program I found some strange happening with pdb and pydb.
>
> I like pydb because let me restart the program and nicer features, but if
> errors pop up, then it will forget all variables (globals and locals gone).
I'm not completely
Hi,
while testing my program I found some strange happening with pdb and pydb.
I like pydb because let me restart the program and nicer features, but if
errors pop up, then it will forget all variables (globals and locals gone).
I've to go for pdb because it isn't affected by that problem, but al
Andreas> Am Donnerstag, den 05.01.2006, 15:03 -0800 schrieb
Andreas> [EMAIL PROTECTED]: I know this sounds like brutal, but I've been
Andreas> developing Python code for a decade now, and I've almost never
Andreas> used pdb.py. OTOH I also use gdb only for "bt" from a core
Andr
e even near the term
"light-weight". Actually, when it comes to execution time it's quite
heavy-weight so to say.
> obscure, or change what Python is doing -- something
> I worry about with heavier-duty debuggers. It also
> comes with Python which gives it some kind of credibi
ot consider manually stepping through a
program a costeffective way of debugging. Writting asserts,
instrumentisation, automatic debuggers and tracers are usually much
better spent money.
Consider how complicated it is to apply gdb or pdb say to a CGI program,
running in an embedded chroot environment?
Tino Lange <[EMAIL PROTECTED]> writes:
> R. Bernstein wrote:
> To summarize, I think most of us readers here like your changes or at least
> didn't shout loud enough against it ;-)
Okay. I'll gladly accept whatever positive interpretation someone
wants to offer. :-)
> As I also would like to hav
R. Bernstein wrote:
Hi!
To summarize, I think most of us readers here like your changes or at least
didn't shout loud enough against it ;-)
As I also would like to have a more powerful and gdb-like debugging facility
in out-of-the-box python, I think it would be the best strategy to make a
conso
R. Bernstein wrote:
> Fernando Perez <[EMAIL PROTECTED]> suggests:
>> You may want to try out ipython (the current release candidate from
>> http://ipython.scipy.org/dist/testing/, which has many improvements on this
>> front). The %pdb magic will trigger automatic activation of pdb at any
>> unc
> - There is no way (I know of) to start a python script
> from the command line with the debugger active;
> I always have to modify the source to insert a
> pdb.set_trace().
With python 2.4 you can do
python -m pdb.py yourscript arg1 arg2
Ilya
--
http://mail.python.org/mailman/listinfo
so can't help note that this may be a little
bit of a self-serving statement.)
> A good debugger is a valuable thing, and I've used some incredible
> debuggers, including one that actually implemented DWIM. Stepping
> through the code is one of the least valuable thing a debugger doe
deal with code written by
> consultants who wrote a *lot* of code but are no longer *maintaining*
> the code for various reasons). And one place debuggers tend to come in
> handy is in focused or problem-solving of others' code.
I also read a lot of Python. Cleaning up that which wa
[EMAIL PROTECTED] wrote:
> For me, it (pdb) is mostly useful for understanding flow of
> control and how objects change as that happens. I
> find it easier than constantly modifying the source code.
Do take a look at Komodo, in that case. Idle does a bit of a
job in this direction, and (for me)
hope) it does not
obscure, or change what Python is doing -- something
I worry about with heavier-duty debuggers. It also
comes with Python which gives it some kind of credibilty
in my mind.
For me, it is mostly useful for understanding flow of
control and how objects change as that happe
a lot either - and I write a *lot* of Python.
Some of us may have to *read* a lot of python. (For example I know
many people including myself who have had to deal with code written by
consultants who wrote a *lot* of code but are no longer *maintaining*
the code for various reasons). And one place d
[EMAIL PROTECTED] writes:
> I was disappointed not to see any replies to this.
> I use pdb a lot because most of my debugging needs
> are simple, and I don't need/want the overhead or
> complications of a heavy duty gui debugger.
>
> I used ddd only little many many years ago, but
> compatibility
Mike> I don't use pdb a lot either - and I write a *lot* of Python.
Ditto. I frequently just insert prints or enable cgitb. Sometimes I enable
line tracing for a specific function and the functions it calls using a
tracing decorator. There are lots of things that are easier than breaking
Fernando Perez <[EMAIL PROTECTED]> suggests:
> You may want to try out ipython (the current release candidate from
> http://ipython.scipy.org/dist/testing/, which has many improvements on this
> front). The %pdb magic will trigger automatic activation of pdb at any
> uncaught exception, and '%run
[EMAIL PROTECTED] writes:
> "R. Bernstein" <[EMAIL PROTECTED]> wrote:
>> So what I am suggesting is that it would be helpful to just follow an
>> existing debugger paradigm (or follow more closely) so folks don't
>> have to learn yet another interface.
Actually, you're not talking about changing t
[EMAIL PROTECTED] wrote:
> I hope some of the other problems with it get
> addressed some day:
> - There is no way (I know of) to start a python script
> from the command line with the debugger active;
> I always have to modify the source to insert a
> pdb.set_trace(). I would like somethi
ow we get to the second issue. Python's stack numbering is
> different from the way most (all?) other languages. And "up" and
> "down" in pdb.py follow the Python notion of direction rather than
> what is common among debuggers. Yes, I realize Python's stack
>
n's stack numbering is
different from the way most (all?) other languages. And "up" and
"down" in pdb.py follow the Python notion of direction rather than
what is common among debuggers. Yes, I realize Python's stack
numbering is the one true the right way; I have no doubt th
64 matches
Mail list logo
