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
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
Changes by Yongzhi Pan fossi...@users.sourceforge.net:
--
nosy: +fossilet
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14228
___
___
Changes by Jurko Gospodnetić jurko.gospodne...@gmail.com:
--
components: +email -Interpreter Core
nosy: +Jurko.Gospodnetić, barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14228
___
Changes by R. David Murray rdmur...@bitdance.com:
--
components: +Interpreter Core -email
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14228
___
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
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14228
___
___
Python-bugs-list
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 --
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 rep...@bugs.python.org
http://bugs.python.org/issue14228
telmich added the comment:
And sorry for the long delay...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14228
___
___
Python-bugs-list mailing
Antoine Pitrou pit...@free.fr 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
poq p...@gmx.com 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
R. David Murray rdmur...@bitdance.com 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 rep...@bugs.python.org
R. David Murray rdmur...@bitdance.com 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
Charles-François Natali neolo...@free.fr 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 rep...@bugs.python.org
telmich nico-bugs.python@schottelius.org 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,
Antoine Pitrou pit...@free.fr 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
telmich nico-bugs.python@schottelius.org 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
poq p...@gmx.com 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*
telmich nico-bugs.python@schottelius.org 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
telmich nico-bugs.python@schottelius.org 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
poq p...@gmx.com 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
telmich nico-bugs.python@schottelius.org 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
Charles-François Natali neolo...@free.fr 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,
Charles-François Natali neolo...@free.fr 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
Antoine Pitrou pit...@free.fr 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
Charles-François Natali neolo...@free.fr 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
R. David Murray rdmur...@bitdance.com 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
telmich nico-bugs.python@schottelius.org 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
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14228
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr 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,
31 matches
Mail list logo
