Ilya Sandler added the comment:
I confirm the bug. But I don't think disabling Ctrl-C (SIGINT) handling by
default is a good idea. Proper Ctrl-C support seems like a fundamental feature
for a command line debugger.
However, I think the bug is easily fixable w/o changing SIGINT han
Ilya Sandler added the comment:
I think stuff like this can only be tested out-of-process.
So I added an out-of-process test to test_pdb.py. The test passes with the
fixed pdb.py. (and fails with the original one).
Patch for the test attached.
--
Added file: http://bugs.python.org
New submission from Ilya Sandler :
The following program is misbehaving with python3.2
import signal, time
def sighandler( arg1, arg2): print("got sigint");assert 0
signal.signal( signal.SIGINT, sighandler)
for i in range(100):
print(i)
I'd expect Ctrl-C t
Ilya Sandler added the comment:
Would avoiding PyErr_CheckSignals() while the file object is in inconsistent
state be a reasonable alternative?
I am guessing that it's not that uncommon for a signal handler to need IO (e.g
to log a signal).
If making IO safer is not an option, then I
Ilya Sandler added the comment:
The patch tries to write to stdout in signal handler.
This currently does not work in the python 3.x (see
http://bugs.python.org/issue10478).
--
___
Python tracker
<http://bugs.python.org/issue7
New submission from Ilya Sandler :
http://mail.python.org/pipermail/python-dev/ archives have not been updated for
a couple of weeks now.
A bug?
--
messages: 98775
nosy: isandler
severity: normal
status: open
title: python-dev archives are not updated
Ilya Sandler added the comment:
As of Feb 2, 2010, archives seem to be functioning as expected ;-)
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Ilya Sandler added the comment:
I don't think this is a bug in python (see below for analysis). Furthermore,
os.popen() is deprecated, so I think this issue can be closed.
Here is my understanding of what's happening.
When you execute :
python -c 'import sys, os; sys.stdout
Ilya Sandler added the comment:
I fixed some of the style issues mentioned on appspot. (I was not sure about
some of them and responded to them in appspot comments).
Also sigHandler became sighandler for consistency with the rest of pdb.py.
The new version of the patch is attached
Ilya Sandler added the comment:
Here is a list of Ctrl-C scenarios: ("current" below means the prepatch version
of pdb).
1. program is running (last command was "c", "n", etc). Currently, Ctrl-C
throws debugger into postmortem. Desired behavior: interrupt
New submission from Ilya Sandler :
Here is a sample session:
cheetah:~/comp/python/trunk> ./python ./Lib/pdb.py hello
> /home/ilya/comp/python/trunk/hello(1)()
-> print i
(Pdb) b 1
Breakpoint 1 at /home/ilya/comp/python/trunk/hello:1
(Pdb) commands 1
(com)
Traceback (most re
Ilya Sandler added the comment:
Another iteration of the patch. Now sigint_handler will generate
KeyboardInterrupts when pdb is in the commandloop
I think this guarantees consistent "Ctrl-C interrupts the current pdb action"
behavior and the program is still resumable.
The
Ilya Sandler added the comment:
Another version of the patch is attached ( I think, I fixed all the remaining
style issues).
I'll answer the testing question in a separate post
--
Added file: http://bugs.python.org/file16470/sig.pat
Ilya Sandler added the comment:
new version of the patch is uploaded to bugs.python.org
http://codereview.appspot.com/216067/diff/2001/2002
File Lib/pdb.py (right):
http://codereview.appspot.com/216067/diff/2001/2002#newcode63
Lib/pdb.py:63: def sigint_handler(self, signum, frame):
On 2010/02
Ilya Sandler added the comment:
> Also, can you take a look at how the pdb unittests work and see if you
can come up with a way to unittest the KeyboardInterrupt behavior?
Yes, this is doable. In fact, I already have such tests written (unix only
though). The tests are assert based but
Ilya Sandler added the comment:
I'm attaching a test for Ctrl-C behavior on Linux (the patch itself works on
Windows too, but I am not sure how to send Ctrl-C on windows programatically
and subprocess does not have this functionality either).
The test_pdb2.py module is generic and c
Ilya Sandler added the comment:
Is there anything else I can do for this patch?
--
___
Python tracker
<http://bugs.python.org/issue7245>
___
___
Python-bug
Ilya Sandler added the comment:
I believe python is fully at mercy of underlying system math library.
And as a matter of fact, this C program
#include
#include
main() { printf("%.6f\n", sin(1e22)); }
when compiled as 64-bit app (on linux) produces "-0.852201", but when
Ilya Sandler added the comment:
a note on testing: it should be possible to integrate the tests into existing
test_pdb.py by simply placing subprocess based tests next to doctest-based
tests. This way pdb tests will at least be in a single module. (this is an
approach taken by a patch in
New submission from Ilya Sandler:
Given that Tix imports all names from Tkinter this is likely to result
in confusion.
E.g.
>>> from Tix import *
>>> print Button
Tkinter.Button
>>> print OptionMenu
Tix.OptionMenu
To get to Tkinter's OptionMenu, one needs to d
Ilya Sandler added the comment:
I understand your argument. Yet, I am not sure classes with the same
name are reasonable here. Tix is too intertwined with Tkinter:
E.g a Tix user user can just access Tkinter widgets via Tix:
>>> import Tix
>>> print Tix.Canvas # This i
Ilya Sandler added the comment:
Here is what's happening: when pdb starts up it sets tracing and several
trace events happen before the pdb reaches the first line of the
debugged program. So, pdb has some logic to ignore certain events on
startup (_wait_for_main_pyfile).
On normal startup
New submission from Ilya Sandler :
Currently, pressing Ctrl-C in pdb will terminate the program and throw
the user into post-mortem debugging.
Other debuggers (e.g gdb and pydb) treat Ctrl-C differently: Ctrl-C only
stops the program and the user can resume it if needed.
I believe current pdb
Ilya Sandler added the comment:
No,I don't think patch in the issue #1294 addresses the problem which
I'm trying to solve.
I tried applying patch#1294, and Ctrl-C will still throws your debugger
into postmortem mode and I don't think you can change that by overriding
do_Ke
Ilya Sandler added the comment:
Is not this patch backward incompatible?
E.g any cmd-based application which expects Ctrl-C to propagate to the
top level will be broken by this patch.
As for pdb, I don't think pdb will benefit from this patch: as I believe
that pdb needs something alon
Ilya Sandler added the comment:
> But currently, CTRL-C terminates the session instead of propagating
upstream
I am not sure I understand: currently Ctrl-C generates a
KeyboardInterrupt, which can be caught by the application which can
then decide how to proceed (in particular it can st
Ilya Sandler added the comment:
Here is another case, which I think is even worse.
Range checks are done inconsistently as well:
.../trunk> ./python -c 'import struct; struct.pack("B", 257)
'Traceback (most recent call last):
File "", line 1, in
stru
Ilya Sandler added the comment:
It appears that the different behavior results from trying to preserve
backward compatibility with earlier version of Python
see: http://bugs.python.org/issue1229380
___
Python tracker
<http://bugs.python.org/issue5
Ilya Sandler added the comment:
I think this would be useful for anyone who builds cpython on a
non-mainstream platform.
I know this would have been useful for me when I tried to build cpython
on an older linux distro where libs were installed in a non-std location.
--
nosy: +isandler
Ilya Sandler added the comment:
I tried to understand the cause of failures and I don't see how test_pdb2 could
have caused them ;-).
Here is the relevant part of buildbot timeline:
http://www.python.org/dev/buildbot/trunk/?last_time=1273368351&show_time=7400
The only test failu
New submission from Ilya Sandler :
the token module defines constants for token types e.g
NAME = 1
NUMBER = 2
STRING = 3
NEWLINE = 4
etc.
These constants are very useful for any code which needs to tokenize python
source, yet they are not listed in the documentation.
Is this a
Ilya Sandler added the comment:
I'm attaching a documentation patch.
Do note that there is also a bit of code-level inconsistency: a few tokens
(COMMENT, NL) are defined in tokenize module which is strange and inconvenient.
Should that be fixed too? (by moving token definitions into
Ilya Sandler added the comment:
> * I would list them all in one directive, like this:
Ok, done. Attaching the updated patch
> There is no description in that directive. Best move part of the
description above them in it.
I am not sure I understand your request. Could you clarify?
New submission from Ilya Sandler :
a session attached:
cheetah:~/wrk/svn/psi-poly5/poly/aut/prof> ~/comp/python/trunk/python -m pstats
prof.out
Welcome to the profile statistics browser.
% stats 20 \
Thu Jul 8 17:50:27 2010prof.out
197258358 function calls (197187736 primit
34 matches
Mail list logo
