[issue15033] Different exit status when using -m
New submission from Kamil Kisiel ka...@kamilkisiel.net: Python returns a different exit status when an exception is raised and -m is used as opposed to just running a module. A short example, let's call it foo.py: def main(): raise ValueError() if __name__ == '__main__': main() When run with python foo.py the exit status of the process is 1. If run with python -mfoo the exit status of the process is 255. -- messages: 162501 nosy: kisielk priority: normal severity: normal status: open title: Different exit status when using -m type: behavior versions: Python 2.6, Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15033 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12423] signal handler doesn't handle SIGABRT from os.abort
Kamil Kisiel ka...@kamilkisiel.net added the comment: Here's my proposed patch for the documentation, against the head of the 2.7 branch. -- keywords: +patch Added file: http://bugs.python.org/file22570/os.rst.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12423] signal handler doesn't handle SIGABRT from os.abort
Kamil Kisiel ka...@kamilkisiel.net added the comment: The application is interfacing with a C library that uses abort() to signal fatal errors (horrible, I know..). Instead of core dumping I would like to be able to handle these errors at the Python level and do something else. It's starting to sound like that might be impossible. You explanation of the abort() behaviour makes sense to me. However, if that's the case then this portion of the docs appears to be incorrect: Be aware that programs which use signal.signal() to register a handler for SIGABRT will behave differently. Maybe my interpretation is wrong, but I would read behave differently as call the signal handler instead in this case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12423] signal handler dpes
Changes by Kamil Kisiel ka...@kamilkisiel.net: -- nosy: kisielk priority: normal severity: normal status: open title: signal handler dpes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12423] signal handler doesn't handle SIGABRT from os.abort
New submission from Kamil Kisiel ka...@kamilkisiel.net: It seems that registering a signal handler for SIGABRT doesn't handle the signal from os.abort(). Example code: import signal, os import time def handler(signum, frame): print Signal! raise Exception() signal.signal(signal.SIGABRT, handler) os.abort() The result is the process still core dumps instead of raising an exception. If instead of os.abort I call time.sleep(10) and then send a kill -ABRT from a shell, the exception is raised as expected. I tried this with Python 2.6 on Gentoo, 2.7 on FC 14, and 2.6 on OS X 10.6.7 with the same result. Based on the documentation for os.abort, I would expect this to work: Generate a SIGABRT signal to the current process. On Unix, the default behavior is to produce a core dump; on Windows, the process immediately returns an exit code of 3. Be aware that programs which use signal.signal() to register a handler for SIGABRT will behave differently. -- title: signal handler dpes - signal handler doesn't handle SIGABRT from os.abort versions: +Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9933] os module does not have the documented EX_NOTFOUND attribute
New submission from Kamil Kisiel kisi...@users.sourceforge.net: The library documentation (http://docs.python.org/library/os.html) states: os.EX_NOTFOUND Exit code that means something like “an entry was not found”. Availability: Unix. New in version 2.3. However, on both my Linux and OS X installs of OS X this happens: python Python 2.6.2 (r262:71600, Oct 24 2009, 03:15:21) [GCC 4.4.1 [gcc-4_4-branch revision 150839]] on linux2 Type help, copyright, credits or license for more information. im import os os.EX_NOTFOUND Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'module' object has no attribute 'EX_NOTFOUND' Unfortunately I don't have another Python version available to test with at the moment so I'm not sure if this affects other versions as well. -- components: Library (Lib) messages: 117245 nosy: kisielk priority: normal severity: normal status: open title: os module does not have the documented EX_NOTFOUND attribute type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9933 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9933] os module does not have the documented EX_NOTFOUND attribute
Kamil Kisiel kisi...@users.sourceforge.net added the comment: That should have read Linux and OS X installs of *Python*. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9933 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9933] os module does not have the documented EX_NOTFOUND attribute
Kamil Kisiel kisi...@users.sourceforge.net added the comment: I mostly wanted to just report the issue rather than propose a solution, so I'm in favor of whatever everyone feels is best. As for how I came across the issue, it was mostly curiosity, I wanted to see the numerical value of all the os.EX_* constants and was printing them out on the screen when I stumbled upon this. If there's no chance of it working, which seems to be the case, I agree it should probably be just removed from the documentation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9933 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7951] Should str.format allow negative indexes when used for __getitem__ access?
Kamil Kisiel kisi...@users.sourceforge.net added the comment: While I agree this functionality isn't strictly necessary I think it makes sense from a semantic point of view. I ran in to this issue today while writing some code and I simply expected the negative syntax to work, given that the format string syntax otherwise very closely resembles standard array and attribute access. It would be nice to see this make it in eventually for consistency's sake. -- nosy: +kisielk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
