[issue14228] It is impossible to catch sigint on startup in python code

[telmich]

telmich added the comment:

Victor, the problem is *not* that python exits. This is fine and virtually 
every other unix program behaves like that.

The problem is that python throws an ugly-to-read and completly senseless 
backtrace to the novice (end!) user by default. Backtraces are great for 
debugging and should be treated as such, but not presented to an end user by 
default.

But I as a developer, who wants to prevent the user seeing a backtrace while 
she does the most normal thing, this places a huge burden on me and I need to 
use undocumented workarounds to try to prevent this - in the case of a try... 
except block around my whole program even without suceess.

The point is that no programming language should shout its internals to an end 
user and prevent the developer from cushion it easily.

Think about "ls -lR" that throws debugging symbols at you, because you 
interrupted it - you would not want to see them, nor what you be happy if you 
had to cushion and especially not if this was not documented and hard to do.

So in short my request is to make python more user friendly by cushion the 
unnecessary backtrace of a Ctrl-C printed out.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14228] It is impossible to catch sigint on startup in python code

[STINNER Victor]

STINNER Victor added the comment:

Sorry, but I don't understand this issue. Well, I understood the issue as "When 
I press CTRL+c to interrupt Python, Python does exit". What's wrong with that? 
Why do you send CTRL+c if you don't want Python to exit?

Using custom signal handler (SIG_IGN), it would be possible to ignore SIGINT 
during Python initialization. Using pthread_sigmask(), it is possible to defer 
the handling of the signal until user is able to setup its own custom signal 
handler (or just use try/except KeyboardInterrupt). But I don't like these 
options. I would like to be able to kill (stop) Python as early as possible 
with CTRL+c.

If you are only worried by the long traceback when importing the site module is 
interrupted, you can use -S. On UNIX, you can then use signal.pthread_sigmask() 
to defer the handling of SIGINT.

The whole issue remembers me the dummy question: "is the finally block executed 
even if I unplug the power cable?".

> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652926

This issue can be solved using python -S, calling signal.signal(SIGINT, 
signal.SIG_DFL) and then import the site module manually.

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14228] It is impossible to catch sigint on startup in python code

[Yongzhi Pan]

Changes by Yongzhi Pan :


--
nosy: +fossilet

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14228] It is impossible to catch sigint on startup in python code

[Jurko Gospodnetić]

Jurko Gospodnetić added the comment:

This issue is related to issue #19983 on Windows.

  Also, I do not think the suggested -z option implementation should be 
accepted 'as is'.

  On Unix it would make Ctrl-C silently terminate the process if it occurs 
before default Python signal handling is enabled. I do not know what effect 
this would have on Windows - possibly the signal would simply be ignored & lost.

  It would also still leave a slight window between when Python sets up its 
default SIGINT handling and when user code has a chance to set up its own.

  My first instinct is to not do that and instead add an option to block SIGINT 
handling and allow user code to enable its own or default Python handling as it 
wishes and then unblock SIGINT handling. Note that by 'blocking' a signal I do 
not mean losing/ignoring it but delaying its handling until signal handling is 
unblocked.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14228] It is impossible to catch sigint on startup in python code

[R. David Murray]

Changes by R. David Murray :


--
components: +Interpreter Core -email

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14228] It is impossible to catch sigint on startup in python code

[Jurko Gospodnetić]

Changes by Jurko Gospodnetić :


--
components: +email -Interpreter Core
nosy: +Jurko.Gospodnetić, barry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14228] It is impossible to catch sigint on startup in python code

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[telmich]

telmich added the comment:

And sorry for the long delay...

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[telmich]

telmich added the comment:

+ parameter -z based change of behaviour

--
Added file: 
http://bugs.python.org/file27925/init_sigs_after_site_parameter_z.diff

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[telmich]

telmich added the comment:

I created two diffs to solve the problem:

a) a static late init of the signal handler
b) configurable late init (using python -z)

Both apply against latest mercurial code:

[15:20] brief:cpython% ./python -V
Python 3.4.0a0
[15:20] brief:cpython% ./python -h | grep -- -z
-z : initialise signals after 'import site'
[15:20] brief:cpython% 


Using shellpart.sh (the original one) and using the newly compiled python 
binary (with -z), works fine:

[15:18] brief:python-traceback-test% ./shellpart.sh 
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
^C

It would be great if you apply either patch:

the static one is fine for me, but changes the behaviour => may not be suited 
for everyone. Otoh, it feels pretty clean to do a late signal change anyway.

the parameter based one lets the user choose whether to use traceback'd version 
or the "unix default" version -> choose this, if you want to ensure backwards 
compatibility.

--
keywords: +patch
Added file: http://bugs.python.org/file27924/init_sigs_after_site_static.diff

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[R. David Murray]

R. David Murray  added the comment:

> Limited by what?

The alphabet.

I suppose we could use a -- option, but somebody would have to add support for 
those.

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[poq]

poq  added the comment:

> Because the available space for command line switches is rather limited

Limited by what?

> "MYENVVAR=foo python ..."

That does not work with hashbangs (and env is kludgey).

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Why an environment variable instead of a command line switch (as
> suggested by Ian Jackson)? Shouldn't a script be able to decide for
> itself how it handles signals?

Because the available space for command line switches is rather limited, and 
this isn't an important option.

This issue applies only to POSIX systems AFAIK, and it's easy to force an env 
var when running an executable ("MYENVVAR=foo python ...").

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[R. David Murray]

R. David Murray  added the comment:

@telmich: I think you will have more success at getting what you want if you 
work with us rather than being confrontational.  Respect that we have reasons 
for doing things a certain way (and not because we are stupid), and we will 
respect your perspective more, and be more likely to do something about the 
real problem that you face.

Or, you could submit a patch...and again work *with* us to get it accepted.

Emitting a traceback on KeyboardInterrupt has served us well in the past, even 
in the startup case to which you are pointing.  If someone makes a mistake in 
site.py or similar and causes python startup to hang, a traceback on keyboard 
interrupt is exactly what you want.  You may think that this situation is 
unlikely to occur, but it is far *more* likely to occur than your 
situation...given, as Antoine said, that you are the first person to report 
this as a problem.

So, we need a solution that serves both use cases.  An environment flag or 
command line option seems to fit the bill.

Now we need a patch.

As far as feature request vs bug, fixing this without removing an existing 
feature (interrupting a hung startup with a traceback) requires a new option or 
environment variable, and therefore *by our rules* this can only go into 3.3.  
That makes it an enhancement by our (project specific) definition, regardless 
of whether or not it is a bug by the broader definition of bug.

--
stage:  -> needs patch

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[poq]

poq  added the comment:

> No, the point is that the exception may be caused by a real bug and having 
> the traceback is tremendously useful to debug such situations. [...] 
> KeyboardInterrupt is not different in this regard from, say, 
> ZeroDivisionError.

KeyboardInterrupt *is* different though. It is caused by the user instead of by 
any bug.

Of course, it can still be useful to know where the program was interrupted, so 
showing a traceback for KeyboardInterrupt by default makes sense IMO.

> As I said, a possible solution is to allow users to alter the default signal 
> handling (using an env var).

Why an environment variable instead of a command line switch (as suggested by 
Ian Jackson)? Shouldn't a script be able to decide for itself how it handles 
signals?

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[telmich]

telmich  added the comment:

Antoine,

let me explain again: I do not say, python should not print uncaught exceptions.

My point here is that an exception is thrown, which is not catchable at all and 
this results in random and misleading errors.

I really hope you understand that this is the core problem. It's not about 
printing uncaught exceptions.

And being the first to report is not something I feel is a bad sign.

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Don't be offended, but this looks like a software coded by a 12 years
> old, who is proud about it and does not accept an error being an error
> and insists on doing it right, although it's a common understanding
> that throwing errors in non error situations.

No, the point is that the exception may be caused by a real bug and
having the traceback is tremendously useful to debug such situations.
So the Python runtime by default prints out the whole traceback when an
uncaught exception occurs. KeyboardInterrupt is not different in this
regard from, say, ZeroDivisionError.

As I said, a possible solution is to allow users to alter the default
signal handling (using an env var).

(note that, AFAICT, you're the first to report a problem here, although
this behaviour has existed for ages)

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[telmich]

telmich  added the comment:

Hello François,

I'm confused about your statement: You prefer to throw random and useless error 
messages to users who are using python instead of doing a clean shutdown like 
every other application by default?

Don't be offended, but this looks like a software coded by a 12 years old, who 
is proud about it and does not accept an error being an error and insists on 
doing it right, although it's a common understanding that throwing errors in 
non error situations.

I would have imagined a more mature understanding and broader view of python 
developers.

If you're not willing to fix this bug but insist on doing it the wrong way by 
default, I'd recommened to reject this bug so that the problem, the reason and 
the reason why it continues to exists are cleanly documented.

Cheers,

Nico

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[Charles-François Natali]

Charles-François Natali  added the comment:

> In any case, I'd appreciate, if cpython would be changed to something more 
> sane/less verbose by default.

By default, certainly not.

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[telmich]

telmich  added the comment:

Oh yes, you are right. Sorry for the confusion.

When modifying caller.py to only print(), everything works.

But then I've a different problem: If I want to exit(1),
in case I get a SIGINT, I'd like to try to import sys. But trying to import 
sys, will probably fail again, because the user is still pressing ctrl-c:


[17:05] brief:python-traceback-test% ./caller.py 
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
^Ccaught signint in child
[17:05] brief:python-traceback-test% ./caller.py
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
^Ccaught signint in child
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "/usr/lib/python3.2/io.py", line 60, in 
[17:05] brief:python-traceback-test% import _io
  File "/usr/lib/python3.2/os.py", line 22, in 
"""
KeyboardInterrupt
./shellpart.sh: line 7: 23123 Aborted ./__testpython


I'll change my production code to run with -S and restoring SIGINT and report 
back.

In any case, I'd appreciate, if cpython would be changed to something more 
sane/less verbose by default.

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[poq]

poq  added the comment:

> It seems not even using -S fixes the problem

That's because you try to use re and os in your except block, and the 
KeyboardInterrupt is raised before they are imported.

--
nosy: +poq

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[telmich]

telmich  added the comment:

I think setting up SIGINT after importing site is a good solution: It will kill 
the program as expected and as soon as the user takes over control, she can 
decide what todo.

In which stage/part is the python interpreter when
I guess/hope that the race condition between initsigs(); would have been moved 
downwards?

I'm asking, because if 'import site' is done, the maximum output seen that 
could occur is

KeyboardInterrupt


if there is no code around there. Which looks way more sane that what I see 
currently.

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[telmich]

telmich  added the comment:

It seems not even using -S fixes the problem:

[16:25] brief:python-traceback-test% head -n 2 caller.py 
#!/usr/bin/python3 -S

[16:25] brief:python-traceback-test% ./caller.py 
Indirect child being called
Indirect child being called
Indirect child being called
^Ccaught signint in parent
Traceback (most recent call last):
  File "/usr/lib/python3.2/functools.py", line 176, in wrapper
result = cache[key]
KeyError: (, '[ \\f\\t]*(\\r?\\n[ 
\\f\\t]*)*(#[^\\r\\n]*)?((([0-9]+[jJ]|(([0-9]+\\.[0-9]*|\\.[0-9]+)([eE][-+]?[0-9]+)?|[0-9]+[eE][-+]?[0-9]+)[jJ])|(([0-9]+\\.[0-9]*|\\.[0-9]+)([eE][-+]?[0-9]+)?|[0-9]+[eE][-+]?[0-9]+)|(0[xX][0-9a-fA-F]+|0[bB][01]+|0[oO][0-7]+|(?:0+|[1-9][0-9]*)))|((\\*\\*=?|>>=?|<<=?|!=|//=?|->|[+\\-*/%&|^=<>]=?|~)|[][(){}]|(\\r?\\n|\\.\\.\\.|[:;.,@]))|([bB]?[rR]?\'[^\\n\']*(?:.[^\\n\']*)*\'|[bB]?[rR]?"[^\\n"]*(?:.[^\\n"]*)*")|\\w+)',
 32)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./__testpython", line 4, in 
import site
  File "/usr/lib/python3.2/site.py", line 58, in 
import traceback
  File "/usr/lib/python3.2/traceback.py", line 3, in 
import linecache
  File "/usr/lib/python3.2/linecache.py", line 10, in 
import tokenize
  File "/usr/lib/python3.2/tokenize.py", line 118, in 
_compile, (Token, PseudoToken, Single3, Double3))
  File "/usr/lib/python3.2/tokenize.py", line 115, in _compile
return re.compile(expr, re.UNICODE)
  File "/usr/lib/python3.2/re.py", line 206, in compile
[16:25] brief:python-traceback-test% return _compile(pattern, flags)
  File "/usr/lib/python3.2/re.py", line 255, in _compile
return _compile_typed(type(pattern), pattern, flags)
  File "/usr/lib/python3.2/functools.py", line 180, in wrapper
result = user_function(*args, **kwds)
  File "/usr/lib/python3.2/re.py", line 267, in _compile_typed
return sre_compile.compile(pattern, flags)
  File "/usr/lib/python3.2/sre_compile.py", line 495, in compile
code = _code(p, flags)
  File "/usr/lib/python3.2/sre_compile.py", line 477, in _code
_compile_info(code, p, flags)
  File "/usr/lib/python3.2/sre_compile.py", line 366, in _compile_info
lo, hi = pattern.getwidth()
  File "/usr/lib/python3.2/sre_parse.py", line 163, in getwidth
i, j = av[1].getwidth()
  File "/usr/lib/python3.2/sre_parse.py", line 153, in getwidth
l, h = av.getwidth()
  File "/usr/lib/python3.2/sre_parse.py", line 163, in getwidth
i, j = av[1].getwidth()
  File "/usr/lib/python3.2/sre_parse.py", line 153, in getwidth
l, h = av.getwidth()
  File "/usr/lib/python3.2/sre_parse.py", line 163, in getwidth
i, j = av[1].getwidth()
  File "/usr/lib/python3.2/sre_parse.py", line 153, in getwidth
l, h = av.getwidth()
  File "/usr/lib/python3.2/sre_parse.py", line 163, in getwidth
i, j = av[1].getwidth()
  File "/usr/lib/python3.2/sre_parse.py", line 153, in getwidth
l, h = av.getwidth()
  File "/usr/lib/python3.2/sre_parse.py", line 147, in getwidth
REPEATCODES = (MIN_REPEAT, MAX_REPEAT)
KeyboardInterrupt

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./__testpython", line 26, in 
if re.match("__", os.path.basename(sys.argv[0])):
NameError: name 're' is not defined

--
Added file: http://bugs.python.org/file24993/caller.py

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> > Or we could change Py_InitializeEx() to setup the signal handlers
> > after having imported the site module:
> 
> Note that I don't really like this solution, because it's better to
> setup handlers for fatal signals (SIGPIPE, SIGXF...) before executing
> arbitrary Python code (site).

Agreed. I think we'd better disable SIGINT initialization when a certain
environment variable is set.
(AFAICT, the issue is only about SIGINT since it's the only one where
the default behaviour is overriden)

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[Charles-François Natali]

Charles-François Natali  added the comment:

> Or we could change Py_InitializeEx() to setup the signal handlers
> after having imported the site module:

Note that I don't really like this solution, because it's better to
setup handlers for fatal signals (SIGPIPE, SIGXF...) before executing
arbitrary Python code (site).

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[Charles-François Natali]

Charles-François Natali  added the comment:

> for everybody who is not *programming* python (imagine there is a *real* 
> user) the tracebacks are useless. Even worse, because the error messages are 
> *changing*, because of different library parts not catching the exception.

Well, I also use it sometimes ;-)

> The problem here is that the user is confronted with unwanted output, 
> produced by the interpreter, which is not possible to be caught by a 
> programmer to prevent this situation happening.

You can start the interpreter with '-S' to avoid importing the site
module, then:

"""
import signal
signal.signal(signal.SIGINT, signal.SIG_DFL)

import site
site.main()

[...]
"""

or

"""
try:
import site
site.main()

import signal
signal.signal(signal.SIGINT, signal.SIG_DFL)
except KeyboardInterrupt:
whatever

[...]
"""

Or we could change Py_InitializeEx() to setup the signal handlers
after having imported the site module:
"""
--- cpython-93769b8ff40b/Python/pythonrun.c 2012-01-19
10:29:48.0 +
+++ cpython/Python/pythonrun.c  2012-03-20 11:27:37.0 +
@@ -313,9 +313,6 @@
 if (initfsencoding(interp) < 0)
 Py_FatalError("Py_Initialize: unable to load the file system codec");

-if (install_sigs)
-initsigs(); /* Signal handling stuff, including initintr() */
-
 initmain(); /* Module __main__ */
 if (initstdio() < 0)
 Py_FatalError(
@@ -333,6 +330,9 @@

 if (!Py_NoSiteFlag)
 initsite(); /* Module site */
+
+if (install_sigs)
+initsigs(); /* Signal handling stuff, including initintr() */
"""

Note, however, that there will always be a race window, if the signal
is delivered after the signal handlers have been setup and the first
line of the user code is executed.

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[telmich]

telmich  added the comment:

Dear Charles-François,

for everybody who is not *programming* python (imagine there is a *real* user) 
the tracebacks are useless. Even worse, because the error messages are 
*changing*, because of different library parts not catching the exception.

Thus someone who is not used to python must have the impression that something 
must be really broken, if random errors appear on pressing the de-facto 
standard key kombination to exit a program.

The problem here is that the user is confronted with unwanted output, produced 
by the interpreter, which is not possible to be caught by a programmer to 
prevent this situation happening.

It is like the Windows 3.11 error message boxes, which never made sense to you, 
but appeared way too often and made you feel bad (hope this makes the problem 
more clear).

--

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[R. David Murray]

R. David Murray  added the comment:

If one could distinguish that python had ended because of a sigint from the 
error code, then it would be possible for the caller to throw away stderr in 
that case.  I agree with the OP that that having to deal with the traceback 
when you know what you want instead is a bit of a pain, but it may be better 
than an unclean shutdown.  (I don't know if it is, because I don't know the 
possible failure modes from an unclean shutdown of the Python startup code).

--
nosy: +r.david.murray

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[Charles-François Natali]

Charles-François Natali  added the comment:

I must be missing something, but I fail to see the problem here.
Basically, when SIGINT is received before the user code is run, it's caught by 
the default handler which prints a traceback and exits. What's wrong with that? 
Not catching SIGINT would result in an unclean exit, and I don't see how that 
would be an improvement.
The exit code may be a valid request, but that's another story.

--
nosy: +neologix

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue14228] It is impossible to catch sigint on startup in python code

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, I see. Would an option to disable the default SIGINT handlers (and let the 
OS kill the process) be an acceptable solution to your use case?

Keep in mind that letting the OS kill the process will bypass any destructors 
at the Python level, so for example some buffered file data may not be flushed 
properly, etc.

By the way, if I'm not mistaken, the problem is only with SIGINT, right?

--
components: +Interpreter Core
title: SIGINT (Ctrl-C) not caught at startup -> It is impossible to catch 
sigint on startup in python code
type: crash -> enhancement
versions: +Python 3.3 -Python 3.2

___
Python tracker 

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