[issue14228] SIGINT (Ctrl-C) not caught at startup

2012-03-09 Thread telmich
telmich added the comment: You are right, there is no different behaviour as parent or child in general. I used this example python => shell => python, because it is actually being used like this in cdist (first link in the first post). The problem arises there, because python is called many

[issue14228] SIGINT (Ctrl-C) not caught at startup

2012-03-09 Thread Antoine Pitrou
Antoine Pitrou added the comment: > The problem is *NOT* in the parent: The problem is in the *CHILD* that > is being called from the shell that is throwing a traceback, which I > cannot prevent in the python code. Python does not (at least, should not) run differently as a child or as a parent

[issue14228] SIGINT (Ctrl-C) not caught at startup

2012-03-09 Thread telmich
telmich added the comment: The problem is *NOT* in the parent: The problem is in the *CHILD* that is being called from the shell that is throwing a traceback, which I cannot prevent in the python code. Please run the script yourself and try to get around the problem, you'll notice it's not p

[issue14228] SIGINT (Ctrl-C) not caught at startup

2012-03-08 Thread Antoine Pitrou
Antoine Pitrou added the comment: Opened issue14229 for the "signal number as exit code" enhancement as mentioned on the Debian issue tracker. -- ___ Python tracker ___ ___

[issue14228] SIGINT (Ctrl-C) not caught at startup

2012-03-08 Thread Antoine Pitrou
Antoine Pitrou added the comment: > Regarding "feature request": I think this is a *bug*, not a feature > request: For me, it is impossible to handle SIGINT correctly with my > code, because it is half-handled (exception raised, but impossible to > catch) by python itself. In the trace you just

[issue14228] SIGINT (Ctrl-C) not caught at startup

2012-03-08 Thread telmich
telmich added the comment: Regarding "feature request": I think this is a *bug*, not a feature request: For me, it is impossible to handle SIGINT correctly with my code, because it is half-handled (exception raised, but impossible to catch) by python itself. Imho this behaviour should not be

[issue14228] SIGINT (Ctrl-C) not caught at startup

2012-03-08 Thread telmich
telmich added the comment: This does not change a thing: Indirect child being called ^CTraceback (most recent call last): File "/usr/lib/python3.2/functools.py", line 176, in wrapper caught signint in parent result = cache[key] KeyError: (, '[ \\f\\t]*((\\r?\\n|#[^\\r\\n]*|([bB]?[rR]

[issue14228] SIGINT (Ctrl-C) not caught at startup

2012-03-08 Thread Antoine Pitrou
Antoine Pitrou added the comment: Try to enclose the whole code (including the imports) in the try...except block. I'm not sure why this matters, though. If you want Python to have a different return code when terminated by a KeyboardInterrupt, then I agree it is a valid feature request.

[issue14228] SIGINT (Ctrl-C) not caught at startup

2012-03-08 Thread telmich
telmich added the comment: And here's the actual python code -- Added file: http://bugs.python.org/file24756/caller.py ___ Python tracker ___ ___

[issue14228] SIGINT (Ctrl-C) not caught at startup

2012-03-08 Thread telmich
New submission from telmich : Hello, pressing ctrl-c or having sigint delivered to the python process in its startup phase results in random tracebacks displayed. This is related to issue3137, but actually happening in Python 3.2.2 on archlinux. We noticed this during development of the cdis