[issue13120] Default nosigint option to pdb.Pdb() prevents use in non-main thread

[Ilya Sandler]

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/file23796/test_pdb.py.patch

___
Python tracker 
<http://bugs.python.org/issue13120>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13120] Default nosigint option to pdb.Pdb() prevents use in non-main thread

[Ilya Sandler]

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 handling. 
Basically, just put try/except around signal.signal, catch the ValueError and 
proceed. Would this approach solve your problem?

Patch attached.

PS. and here is a small program demonstrating the bug (just run it and execute 
"c" command at pdb prompt)

 import threading
 import pdb

 def start_pdb():
pdb.Pdb().set_trace()
x = 1
y = 1

 t = threading.Thread( target=start_pdb)
 t.start()

--
keywords: +patch
nosy: +isandler
Added file: http://bugs.python.org/file23791/thread_sigint.patch

___
Python tracker 
<http://bugs.python.org/issue13120>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)

[Ilya Sandler]

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/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10478] Ctrl-C locks up the interpreter

[Ilya Sandler]

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 think, this limitation needs to be 
documented (especially, given that this seems to be a behavior change from 
Python 2.x).

--

___
Python tracker 
<http://bugs.python.org/issue10478>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10478] Ctrl-C locks up the interpreter

[Ilya Sandler]

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 to terminate the program with AssertionError and that's 
indeed what happens under python2.7.

But with python3.2a, I get "Assertion Error" 1 out ~10 times. The other 9 
times, the program locks up (goes to sleep? ps shows process status as "S"). 
After the program locks up, it does not respond to subsequent "Ctrl-C" presses.

This is on 64-bit Ubuntu 8.04.

--
components: Interpreter Core
messages: 121860
nosy: isandler
priority: normal
severity: normal
status: open
title: Ctrl-C locks up the interpreter
type: behavior
versions: Python 3.2

___
Python tracker 
<http://bugs.python.org/issue10478>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9209] pstats module crashes on trailing backslash

[Ilya Sandler]

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 primitive calls) in 321.090 CPU 
seconds

Traceback (most recent call last):
  File "/home/ilya/comp/python/trunk/Lib/runpy.py", line 162, in 
_run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/home/ilya/comp/python/trunk/Lib/runpy.py", line 72, in _run_code
exec code in run_globals
  File "/home/ilya/comp/python/trunk/Lib/pstats.py", line 681, in 
browser.cmdloop()
  File "/home/ilya/comp/python/trunk/Lib/cmd.py", line 142, in cmdloop
stop = self.onecmd(line)
  File "/home/ilya/comp/python/trunk/Lib/cmd.py", line 219, in onecmd
return func(arg)
  File "/home/ilya/comp/python/trunk/Lib/pstats.py", line 657, in do_stats
return self.generic('print_stats', line)
  File "/home/ilya/comp/python/trunk/Lib/pstats.py", line 578, in generic
getattr(self.stats, fn)(*processed)
  File "/home/ilya/comp/python/trunk/Lib/pstats.py", line 359, in print_stats
width, list = self.get_print_list(amount)
  File "/home/ilya/comp/python/trunk/Lib/pstats.py", line 332, in get_print_list
list, msg = self.eval_print_amount(selection, list, msg)
  File "/home/ilya/comp/python/trunk/Lib/pstats.py", line 306, in 
eval_print_amount
if re.search(sel, func_std_string(func)):
  File "/home/ilya/comp/python/trunk/Lib/re.py", line 142, in search
return _compile(pattern, flags).search(string)
  File "/home/ilya/comp/python/trunk/Lib/re.py", line 245, in _compile
raise error, v # invalid expression
sre_constants.error: bogus escape (end of line)

--
components: Library (Lib)
messages: 109656
nosy: isandler
priority: normal
severity: normal
status: open
title: pstats module crashes on trailing backslash
type: behavior
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue9209>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8968] token type constants are not documented

[Ilya Sandler]

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?


>  NL and COMMENT are defined in tokenize because they are neither 
defined nor used by the Python tokenizer.

Oh, I just realized the source of my misunderstanding: token.py captures token 
types as they are returned by python's own tokenizer. While tokenize module  
does its own tokenization and produces results which are a bit different. 
COMMENT and NL tokens is one of the differences but there is a difference in 
how the operation tokens are treated. In fact tokenize's docstring explicitly 
says so.

... It is designed to match the working of the Python tokenizer exactly, except 
that it produces COMMENT tokens for comments and gives type OP for all 
operators ...

I think this clarification should go into official docs as well, would you 
agree?

PS. even with this clarification, I find the situation quite a bit confusing: 
especially given that tok_name dict from token module does have a name for 
COMMENT and that name is inserted by tokenize module..  So I still feel that 
just adding COMMENT and NL to token module (with clarification that they are 
not generated by the python's own tokenizer) would be a bit cleaner.

--
Added file: http://bugs.python.org/file17652/token.rst.patch.v2

___
Python tracker 
<http://bugs.python.org/issue8968>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8968] token type constants are not documented

[Ilya Sandler]

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 token module)

--
keywords: +patch
Added file: http://bugs.python.org/file17641/token.rst.patch

___
Python tracker 
<http://bugs.python.org/issue8968>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8968] token type constants are not documented

[Ilya Sandler]

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 documentation bug?

--
assignee: d...@python
components: Documentation
messages: 107509
nosy: d...@python, isandler
priority: normal
severity: normal
status: open
title: token type constants are not documented
versions: Python 3.3

___
Python tracker 
<http://bugs.python.org/issue8968>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)

[Ilya Sandler]

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 failures which have  log files were sparc solaris 10 and ia64 and 
both failures were in test_unittest. All other buildbot failures don't have 
test logs associated with them..

Is there a way to  access test logs for other platforms?

--

___
Python tracker 
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)

[Ilya Sandler]

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 
http://bugs.python.org/issue7964)

Would it be better?

--

___
Python tracker 
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8309] Sin(x) is Wrong

[Ilya Sandler]

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 it's 
compiled as a 32-bit app on the same machine (gcc -m32), it produces "0.462613".

So I don't think this is a bug in python.

--
nosy: +isandler

___
Python tracker 
<http://bugs.python.org/issue8309>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)

[Ilya Sandler]

Ilya Sandler  added the comment:

Is there anything else I can do for this patch?

--

___
Python tracker 
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)

[Ilya Sandler]

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 can be extended to test other 
functionality. But, as discussed earlier, it cannot be easily (if at all) 
integrated into existing test_pdb.py.

Note that the test module will NOT work with existing pdb (as it doesnot have 
expected Ctrl-C) behavior, but on can specify alternative pdb location from 
command line:

  env DEBUG_PDB=./pdb.py ./test_pdb2.py

--
Added file: http://bugs.python.org/file16619/test_pdb2.py

___
Python tracker 
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)

[Ilya Sandler]

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 it should not be difficult to convert 
them to unittest. Moreover, I have many more tests for pdb written in the same 
style. 

However, these tests are not easily (and possibly not at all) integratable with 
existing test_pdb.py module. (See below for the problems). So would it be 
acceptable to have these tests as a separate module (test_pdb2.py or some 
such)? (I might also need some help with integrating the module)

Background
--

Here is the basic problem: testing/debugging a debugger is hard by itself (you 
need to deal with 2 programs at once: the one being debugged and the debugger 
which run intermittently), now throw in doctest and it becomes much harder (as 
everything you do now gets covered by another layer). And now we need to test 
signals and some of the tests will likely be platform specific which makes it 
even worse. 

In contrast, in my tests the snippets of code are written into a tmp file and 
then are fed into debugger, the debugger itself is run as a subprocess. So if a 
test fails, it can be easily rerun under debugger manually and you can  test 
for things like pdb exits and stalls.

Here is a snippet from my pdb tests (just to give an idea how they would look 
like: essentially, send a command to pdb, check the response).


  pdb=PdbTester("pdb_t_hello","""\
  import time
  for i in xrange(1):
 time.sleep(0.05)
  """)

  pdb.pdbHandle.stdin.write("c\n")
  time.sleep(0.01)
  #pdb_t_hello running, try to interrupt it
  pdb.pdbHandle.send_signal(signal.SIGINT)
  pdb.waitForPrompt()
  pdb.queryAndMatch("p i", "0")
  pdb.query("n")
  pdb.query("n")
  pdb.queryAndMatch("p i", "1")
  pdb.query("s")
  pdb.query("s")
  pdb.queryAndMatch("p i","2")
  pdb.pdbHandle.stdin.write("c\n")
  time.sleep(0.03)
  pdb.pdbHandle.send_signal(signal.SIGINT)
  pdb.waitForPrompt()
  pdb.queryAndMatch("p i","3")

--

___
Python tracker 
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)

[Ilya Sandler]

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/28 20:12:00, gregory.p.smith wrote:
> Please move this below the __init__ definition.  It makes classes odd
to read
> when __init__ isn't the first method defined when people are looking
for the
> constructor to see how to use it.

Done.

http://codereview.appspot.com/216067/diff/2001/2002#newcode64
Lib/pdb.py:64: if self.allow_kbdint:
On 2010/02/28 20:12:00, gregory.p.smith wrote:
> Initialize self.allow_kdbint in __init__ so that a SIGINT coming in
before
> _cmdloop has run doesn't cause an AttributeError.

Done.

http://codereview.appspot.com/216067/diff/2001/2002#newcode215
Lib/pdb.py:215: # keyboard interrupts allow for an easy way to interrupt
On 2010/02/28 20:12:00, gregory.p.smith wrote:
> "to cancel the current command"

I changed the wording a bit, should be ok now.

http://codereview.appspot.com/216067/diff/2001/2002#newcode356
Lib/pdb.py:356: #it appears that that when pdb is reading input from a
pipe
On 2010/02/28 20:12:00, gregory.p.smith wrote:
> Space after the # please.

this code
> is?

particular
> interrupted command from the list of commands to run at the current
breakpoint
> but I may be misreading things as I haven't spent much time in pdb.py.

Done. I've also added a comment to explain what's going on.

http://codereview.appspot.com/216067/show

--

___
Python tracker 
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7245] better Ctrl-C support in pdb (program can be resumed) (issue216067)

[Ilya Sandler]

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.patch.v3

___
Python tracker 
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7245] better Ctrl-C support in pdb (program can be resumed)

[Ilya Sandler]

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 "commands" command required a bit of special handling to unroll the changes 
if KbdInt happens.

The patch was tested on Linux and Vista.

--
Added file: http://bugs.python.org/file16384/sig.patch.v2

___
Python tracker 
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8015] pdb "commands" command throws you into postmortem if you enter an empty command

[Ilya Sandler]

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 recent call last):
self.cmdloop()
  File "/home/ilya/comp/python/trunk/Lib/cmd.py", line 142, in cmdloop
stop = self.onecmd(line)
  File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 273, in onecmd
return cmd.Cmd.onecmd(self, line)
  File "/home/ilya/comp/python/trunk/Lib/cmd.py", line 219, in onecmd
return func(arg)
  File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 330, indo_commands
self.cmdloop()
  File "/home/ilya/comp/python/trunk/Lib/cmd.py", line 142, in cmdloop
stop = self.onecm  File "/home/ilya/comp/python/trunk/Lib/bdb.py", line 66, 
in  dispatch_line
self.user_line(frame)
  File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 158, in user_line
self.interaction(frame, None)
  File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 206, in interaction
d(line)
  File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 275, in onecmd
return self.handle_command_def(line)
  File "/home/ilya/comp/python/trunk/Lib/pdb.py", line 293, in 
handle_command_def
func = getattr(self, 'do_' + cmd)
 TypeError: cannot concatenate 'str' and 'NoneType' objects
 Uncaught exception. Entering post mortem debugging
 Running 'cont' or 'step' will restart the program
 > /home/ilya/comp/python/trunk/Lib/pdb.py(293)handle_command_def()
 -> func = getattr(self, 'do_' + cmd)

--
messages: 100057
nosy: isandler
severity: normal
status: open
title: pdb "commands" command throws you into postmortem if you enter an empty 
command
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue8015>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7245] better Ctrl-C support in pdb (program can be resumed)

[Ilya Sandler]

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 the program. This 
is the only scenario supported by the patch.

2. Program is stopped (debugger is interacting with the user). Currently, 
Ctrl-C will throw debugger into postmortem. Desired behaviour: either ignore 
Ctrl-C or abandon the current command (that's what gdb does).

3. Program is stopped and pdb runs one of the commands which catch exceptions 
(e.g "p"). Currently, Ctrl-C will abort the command and return pdb to the 
prompt. I think this behavior should be kept.

4. Program finished (debugger is in postmortem). Currently, Ctrl-C will quit 
the debugger. Desired behavior: either ignore Ctrl-C or abandon the current 
command.

Essentially, I think the best behavior is to have Ctrl-C to interrupt whatever 
pdb is doing and return to the fresh prompt.

I am assuming that behavior on Windows and Linux should be identical/nearly 
identical.

Does the above list make sense?

I would greatly appreciate any feedback/comments/guidance/etc.

--

___
Python tracker 
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7245] better Ctrl-C support in pdb (program can be resumed)

[Ilya Sandler]

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.

However, it appears that I've been a bit over-optimistic about the lack of 
side-effects. In particular, the patch results in an very ugly error message 
when Ctrl-C is pressed while at pdb prompt..


*** AttributeError: AttributeError("'NoneType' object has no attribute 
'f_globals'",)

Everything still seems to be working, but it's definitely ugly (and behaves 
differently on Windows and Linux).

I will try to summarize possible Ctrl-C scenarios in a separate post

--
Added file: http://bugs.python.org/file16288/sig.patch.v1

___
Python tracker 
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1736483] os.popen('yes | echo hello') stuck

[Ilya Sandler]

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.write(os.popen("while :; do echo  yes ; 
done | echo hello").read())'

popen() forks and then execs() a /bin/sh like this

 /bin/sh -c "while :; do echo  yes ; done | echo hello"

But exec() (on Linux at least) inherits the signal handling from the pre-exec 
process for the signals which were set to SIG_IGN or SIG_DFL (see e.g here: 
http://www.gnu.org/software/libc/manual/html_node/Initial-Signal-Actions.html), 
so in this case shell will inherit SIG_IGN setting from python for SIGPIPE.

Furthermore, the "sh" manpage explicitly says that shell will wait for all 
processes in the pipeline. 

So, the sequence of events will be as follows: echo exits, SIGPIPE is delivered 
to the shell and is ignored by the shell and so the shell keeps running the 
while loop forever, so .read() call never reaches the eof and your script 
blocks.

The original "yes|echo" example on MacOsX has likely been caused by the same 
sequence of events. (if "yes" inherits signal handling from shell, then 
"yes|echo"
would not block when invoked from command line, but would block when invoked 
from python)

Installling your own SIGPIPE handler (or resetting SIGPIPE to SIG_DFL as ilgiz 
suggested) should work around this issue.

--
nosy: +isandler

___
Python tracker 
<http://bugs.python.org/issue1736483>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7843] python-dev archives are not updated

[Ilya Sandler]

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/issue7843>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7843] python-dev archives are not updated

[Ilya Sandler]

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

___
Python tracker 
<http://bugs.python.org/issue7843>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1294] Management of KeyboardInterrupt in cmd.py

[Ilya Sandler]

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 start another command
loop or exit with a meaningful message or anything else).

This patch would suppress KeyboardInterrupt and thus interfere with such
applications. Or am I missing something?

--

___
Python tracker 
<http://bugs.python.org/issue1294>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1294] Management of KeyboardInterrupt in cmd.py

[Ilya Sandler]

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 along the lines of patch #7245 for Ctrl-C
(temporary interrupt of execution with ability to resume similar to what
gdb does)

--
nosy: +isandler

___
Python tracker 
<http://bugs.python.org/issue1294>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7245] better Ctrl-C support in pdb (program can be resumed)

[Ilya Sandler]

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_KeyboardInterrupt(): when do_KbdInterrupt() is called you cannot
resume execution (or at least I don't know any way of doing it).

My patch handles the SIGINT directly which allows it to set tracing and
resume the program immediately (and keyboardinterrupt is never raised)

I'll also add comments to patch#1294

--

___
Python tracker 
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7245] better Ctrl-C support in pdb (program can be resumed)

[Ilya Sandler]

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 behavior is user-unfriendly (as wanting to stop
and then resume the execution is a very common use case which is not
supported by pdb at all (I think)).


The attached patch changes pdb's Ctrl-C behavior to match
gdb's: Ctrl-C will stop the program and the user can resume the
execution later.

--
components: Library (Lib)
files: sig.patch.v0
messages: 94764
nosy: isandler
severity: normal
status: open
title: better Ctrl-C support in pdb (program can be resumed)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file15241/sig.patch.v0

___
Python tracker 
<http://bugs.python.org/issue7245>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6719] pdb messes up when debugging an non-ascii program

[Ilya Sandler]

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 only "call" and "line"events need to be ignored and so
that's what pdb did. However, the "coding" directive causes some
additional code to get executed and results in "return" and "exception"
events.

I am attaching the patch to properly ignore irrelevant "return" and
"exception"events on startup. The patch fixes both the startup and the
exit problems.

--
nosy: +isandler
Added file: http://bugs.python.org/file14856/pdb-nonascii.patch.v1

___
Python tracker 
<http://bugs.python.org/issue6719>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5575] Add env vars for controlling building sqlite, hashlib and ssl

[Ilya Sandler]

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

___
Python tracker 
<http://bugs.python.org/issue5575>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5198] Strange DeprecationWarning behaviour in module struct

[Ilya Sandler]

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/issue5198>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5198] Strange DeprecationWarning behaviour in module struct

[Ilya Sandler]

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 
struct.error: ubyte format requires 0 <= number <= 255

.../trunk> ./python -c 'import struct; struct.pack(">B", 257)' 
sys:1: DeprecationWarning: 'B' format requires 0 <= number <= 255

--
nosy: +isandler

___
Python tracker 
<http://bugs.python.org/issue5198>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2059] OptionMenu class is defined both in Tkinter and Tix

[Ilya Sandler]

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 is TkInter's widget
Tkinter.Canvas

>> import Tix.ComboBox #whoops, we've got Tix's combobox
Tix.ComboBox

As a matter of fact, Tix docs seem to explicitly recommend accessing
Tkinter stuff through Tix:

"""The former imports the latter, so to use Tix with Tkinter, all you
need to do is to import one module. In general, you can just import Tix,
and replace the toplevel call to Tkinter.Tk with Tix.Tk"""

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2059>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2059] OptionMenu class is defined both in Tkinter and Tix

[Ilya Sandler]

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 do something like

import Tkinter
Tkinter.OptionMenu

--
components: Library (Lib)
messages: 62250
nosy: isandler
severity: normal
status: open
title: OptionMenu class is defined both in Tkinter and Tix
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2059>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com