[issue9661] 2to3 except fixer does the wrong thing for certain raise statements
New submission from Brodie Rao :
Given the following statements:
raise Foo('bar'), None, baz
raise Foo('bar'), None
2to3 produces:
raise Foo('bar')(None).with_traceback(baz)
raise Foo('bar')(None)
Instead of:
raise Foo('bar').with_traceback(baz)
raise Foo('bar')
--
components: 2to3 (2.x to 3.0 conversion tool)
messages: 114694
nosy: brodie
priority: normal
severity: normal
status: open
title: 2to3 except fixer does the wrong thing for certain raise statements
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/issue9661>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2856] os.listdir doc should mention that Unicode decoding can fail
New submission from Brodie Rao <[EMAIL PROTECTED]>: The documentation for os.listdir should mention that there's a possibility that it can fail to decode paths to unicode objects and that it returns str objects for those paths it couldn't decode. The documentation should also explain when this might happen, and perhaps how to deal with it. The cases that this could happen or how to work around it are beyond my knowledge, but #683592 does mention something about resetting the locale. I don't know if that comment is still relevant, or if it applies to all cases of decoding failure, however. I don't know if this behavior still exists in Python 2.6. If it does, the documentation for 2.6 should be amended as well. -- assignee: georg.brandl components: Documentation messages: 66839 nosy: brodierao, georg.brandl severity: normal status: open title: os.listdir doc should mention that Unicode decoding can fail type: behavior versions: Python 2.3, Python 2.4, Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2856> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3242] Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with sys.stdout reassigned
New submission from Brodie Rao <[EMAIL PROTECTED]>: Running the attached script - which reassigns sys.stdout to an object that proxies sys.stdout, and eventually reassigns it back to the original object - using Apple's distribution of Python 2.5.1 on an x86 machine, I get the following crash: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x7d312298 Crashed Thread: 0 Thread 0 Crashed: 0 ??? 0x00025d33 0 + 154931 1 org.python.python 0x001381c1 PyFloat_FromString + 6196 2 org.python.python 0x001381c1 PyFloat_FromString + 6196 3 org.python.python 0x0014cdce _PyTrash_destroy_chain + 89 4 org.python.python 0x00198bd3 PyErr_Clear + 34 5 org.python.python 0x00132938 PyFile_SoftSpace + 117 6 org.python.python 0x0018b273 PyEval_EvalFrameEx + 7497 7 org.python.python 0x0018f45b PyEval_EvalCodeEx + 1638 8 org.python.python 0x0018f548 PyEval_EvalCode + 87 9 org.python.python 0x001a69ec PyErr_Display + 1896 10 org.python.python 0x001a7016 PyRun_FileExFlags + 135 11 org.python.python 0x001a8982 PyRun_SimpleFileExFlags + 421 12 org.python.python 0x001b3c03 Py_Main + 3095 13 org.python.pythonapp0x1fca 0x1000 + 4042 During the process of whittling down the script to a test case, I experienced other kinds of crashes, or no crash at all. For each iteration of the script, the outcome was always the same, i.e. never inconsistent between runs. All the various crashes I've encountered: :Assertion failed: (gc->gc.gc_refs != 0), function visit_decref, file Modules /gcmodule.c, line 276. Assertion failed: (pool->ref.count > 0), function PyObject_Free, file Objects /obmalloc.c, line 929. [1]33289 illegal hardware instruction python crash.py [1]33352 floating point exception python crash.py [1]33502 segmentation fault python crash.py [1]34303 bus error python crash.py Running this on a different machine running Debian Etch Linux x86 using Debian's Python 2.4 distribution, I get the following crash: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1209882400 (LWP 21471)] 0x080b9ffc in PyEval_EvalCodeEx () (gdb) bt #0 0x080b9ffc in PyEval_EvalCodeEx () #1 0x08100b69 in PyClassMethod_New () #2 0x0805ad9c in PyObject_CallFunction () #3 0x08097594 in PyType_Ready () #4 0x080b79bf in PyEval_EvalFrame () #5 0x080ba755 in PyEval_EvalCodeEx () #6 0x08100b69 in PyClassMethod_New () #7 0x0805ad9c in PyObject_CallFunction () #8 0x08097594 in PyType_Ready () #9 0x080b79bf in PyEval_EvalFrame () #10 0x080ba755 in PyEval_EvalCodeEx () #11 0x08100b69 in PyClassMethod_New () #12 0x0805ad9c in PyObject_CallFunction () #13 0x08097594 in PyType_Ready () #14 0x080b79bf in PyEval_EvalFrame () [the same stack trace repeating over and over...] #141 0x08100b69 in PyClassMethod_New () #142 0x0805ad9c in PyObject_CallFunction () #143 0x08097594 in PyType_Ready () #144 0x080b79bf in PyEval_EvalFrame () #145 0x080ba755 in PyEval_EvalCodeEx () #146 0x08100b69 in PyClassMethod_New () #147 0x0805ad9c in PyObject_CallFunction () #148 0x08097594 in PyType_Ready () #149 0x0807e5e9 in PyObject_GetAttrString () #150 0x08064f91 in PyFile_SoftSpace () #151 0x080b6420 in PyEval_EvalFrame () #152 0x080ba755 in PyEval_EvalCodeEx () #153 0x080ba7b9 in PyEval_EvalCode () #154 0x080dd167 in PyRun_FileExFlags () #155 0x080dd364 in PyRun_SimpleFileExFlags () #156 0x08055ba8 in Py_Main () #157 0x08055032 in main () Using Debian's distribution of Python 2.5, I didn't see any crashes. Using the distribution of Python 2.6b1 from python.org on Mac OS X 10.5 (x86), I saw the same crash: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0xbea0 0x001b7e50 in ?? () (gdb) bt #0 0x001b7e50 in ?? () #1 0x0002bea1 in frame_dealloc (f=0x21db20) at Objects/frameobject.c:417 #2 0x0002bf55 in frame_dealloc (f=0x21f220) at Objects/frameobject.c:425 #3 0x0002bf55 in frame_dealloc (f=0x21f380) at Objects/frameobject.c:425 #4 0x000466db in _PyTrash_destroy_chain () at Objects/object.c:2223 #5 0x000b2dd2 in PyErr_Clear () at Python/errors.c:239 #6 0x00024235 in PyFile_SoftSpace (f=0x3645b0, newflag=0) at Objects/fileobject.c:2141 #7 0x000a11e4 in PyEval_EvalFrameEx (f=0x202f20, throwflag=0) at Python/ceval.c:1622 #8 0x000a45ea in PyEval_EvalCodeEx (co=0x33e968, globals=0x1b7e40, locals=0x1b7e40, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2880 #9 0x000a46f7 in PyEval_EvalCode (co=0x21eddc, globals=0x21eddc, locals=0x21eddc) at Python/ceval.c:495 #10 0x000c99d3 in PyRun_FileExFlags (fp=0xa0125de0, filename=0xb0ec "/Users/brodie/Documents/Code/py-crash/crash5.py&qu
[issue3242] Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with sys.stdout reassigned
Brodie Rao <[EMAIL PROTECTED]> added the comment: Actually, this seems to be a hardware issue, despite the consistency between runs and the duplication on another machine. I think you can ignore/close this bug. Sorry for the noise. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3242> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3242] Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with sys.stdout reassigned
Brodie Rao <[EMAIL PROTECTED]> added the comment: Actually, I've tested this script on another Debian x86 machine and two Ubuntu x86 machines, all which exhibit the exact same crash with their Python 2.4 distributions. I don't think it's a hardware issue, I think there's a legitimate issue here. The crash always originates from PyFile_SoftSpace in PyEval_EvalFrameEx. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3242> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3242] Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with sys.stdout reassigned
Brodie Rao <[EMAIL PROTECTED]> added the comment: Using Python 2.5.2 from python.org on Mac OS X 10.5, I get the same error: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0xad40 0x0052ed30 in ?? () (gdb) bt #0 0x0052ed30 in ?? () #1 0x0002ad41 in frame_dealloc (f=0x61cca0) at Objects/frameobject.c:416 #2 0x0002adf2 in frame_dealloc (f=0x61ea10) at Objects/frameobject.c:424 #3 0x0002adf2 in frame_dealloc (f=0x61eb70) at Objects/frameobject.c:424 #4 0x0004574b in _PyTrash_destroy_chain () at Objects/object.c:2136 #5 0x000aebc2 in PyErr_Clear () at Python/errors.c:231 #6 0x000234fb in PyFile_SoftSpace (f=0x700cb0, newflag=0) at Objects/fileobject.c:2127 #7 0x0009b819 in PyEval_EvalFrameEx (f=0x61b840, throwflag=0) at Python/ceval.c:1608 #8 0x0009f29a in PyEval_EvalCodeEx (co=0x595410, globals=0x52ed20, locals=0x52ed20, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2836 #9 0x0009f3a7 in PyEval_EvalCode (co=0x595410, globals=0x52ed20, locals=0x52ed20) at Python/ceval.c:494 #10 0x000c31d7 in PyRun_FileExFlags (fp=0xa0125de0, filename=0xb0cc, start=257, globals=0x52ed20, locals=0x52ed20, closeit=1, flags=0xbfffef3c) at Python/pythonrun.c:1273 #11 0x000c3583 in PyRun_SimpleFileExFlags (fp=0xa0125de0, filename=0xb0cc, closeit=1, flags=0xbfffef3c) at Python/pythonrun.c:879 #12 0x000d1d27 in Py_Main (argc=1, argv=0xbfffefb8) at Modules/main.c:523 #13 0x1bcc in _start () #14 0x1af9 in start () (gdb) info locals No symbol table info available. (gdb) up #1 0x0002ad41 in frame_dealloc (f=0x61cca0) at Objects/frameobject.c:416 416 Py_CLEAR(*p); (gdb) info locals p = (PyObject **) 0x61cdd8 valuestack = (PyObject **) 0x61cde0 co = (PyCodeObject *) 0x61cdd8 f = (PyFrameObject *) 0x61cca0 [...] (gdb) up #6 0x000234fb in PyFile_SoftSpace (f=0x700cb0, newflag=0) at Objects/fileobject.c:2127 2127PyErr_Clear(); (gdb) info locals v = (PyObject *) 0x0 oldflag = 0 f = (PyObject *) 0x700cb0 (gdb) up #7 0x0009b819 in PyEval_EvalFrameEx (f=0x61b840, throwflag=0) at Python/ceval.c:1608 1608PyFile_SoftSpace(w, 0); (gdb) info locals stack_pointer = (PyObject **) 0x0 next_instr = (unsigned char *) 0x61e5e0 "?(\r" opcode = 0 oparg = 7343280 why = 7343280 err = 0 x = (PyObject *) 0x0 v = (PyObject *) 0x700cb0 w = (PyObject *) 0x u = (PyObject *) 0x700cb0 t = (PyObject *) 0x0 stream = (PyObject *) 0x0 fastlocals = (PyObject **) 0x61b978 freevars = (PyObject **) 0x61b978 retval = (PyObject *) 0x0 tstate = (PyThreadState *) 0x600170 co = (PyCodeObject *) 0x595410 instr_ub = -1 instr_lb = 0 instr_prev = -1 first_instr = (unsigned char *) 0x704034 "d" names = (PyObject *) 0x58a4b0 consts = (PyObject *) 0x597ab0 >From what I see on python.org, the advertised policy is to fix bugs affecting the stability of the interpreter. I don't know if it's relevant to the 2.5 crash, but using Python 2.4.5 from python.org on Debian x86 I'm able to get a more detailed backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210747200 (LWP 11771)] PyEval_EvalCodeEx (co=0xb7cf7ba0, globals=0xb7d30824, locals=0x0, args=0xb7cfd9b8, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2571 2571Py_INCREF(x); (gdb) bt #0 PyEval_EvalCodeEx (co=0xb7cf7ba0, globals=0xb7d30824, locals=0x0, args=0xb7cfd9b8, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2571 #1 0x080ffab9 in function_call (func=0xb7d00064, arg=0xb7cfd9ac, kw=0x0) at Objects/funcobject.c:548 #2 0x0805adbc in PyObject_CallFunction (callable=0xb7d00064, format=0x8115c8b "OO") at Objects/abstract.c:1795 #3 0x08097634 in slot_tp_getattr_hook (self=0xb7cfd9ac, name=0xb7cfdc60) at Objects/typeobject.c:4607 #4 0x080b69b2 in PyEval_EvalFrame (f=0x81a5b6c) at Python/ceval.c:1957 [with the same stack trace as above continuing...] #155 0x080b9785 in PyEval_EvalCodeEx (co=0xb7cf7ba0, globals=0xb7d30824, locals=0x0, args=0xb7cfde58, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741 #156 0x080ffab9 in function_call (func=0xb7d00064, arg=0xb7cfde4c, kw=0x0) at Objects/funcobject.c:548 #157 0x0805adbc in PyObject_CallFunction (callable=0xb7d00064, format=0x8115c8b "OO") at Objects/abstract.c:1795 #158 0x08097634 in slot_tp_getattr_hook (self=0xb7cfd9ac, name=0xb7cfdc60) at Objects/typeobject.c:4607 #159 0x080b69b2 in PyEval_EvalFrame (f=0x81a9084) at Python/ceval.c:1957 #160 0x080b9785 in PyEval_EvalCodeEx (co=0xb7cf7ba0, globals=0xb7d30824, locals=0x0, args=0xb7cfde98, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2741 #161 0x080ffab9 in function_call (func=0xb7d00064, arg=0xb
[issue3242] Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with sys.stdout reassigned
Brodie Rao <[EMAIL PROTECTED]> added the comment: Running with Python 2.5.2 with guard malloc on OS X 10.5 produces a similar crash to that of Python 2.4 on Linux: (gdb) set env DYLD_INSERT_LIBRARIES /usr/lib/libgmalloc.dylib (gdb) run ~/Documents/Code/py-crash/crash5.py Starting program: /Users/brodie/Downloads/Python-2.5.2/python.exe ~/Documents/Code/py-crash/crash5.py GuardMalloc: Allocations will be placed on 16 byte boundaries. GuardMalloc: - Some buffer overruns may not be noticed. GuardMalloc: - Applications using vector instructions (e.g., SSE or Altivec) should work. GuardMalloc: GuardMalloc version 18 GuardMalloc: Allocations will be placed on 16 byte boundaries. GuardMalloc: - Some buffer overruns may not be noticed. GuardMalloc: - Applications using vector instructions (e.g., SSE or Altivec) should work. GuardMalloc: GuardMalloc version 18 Reading symbols for shared libraries +. done Reading symbols for shared libraries .. done GuardMalloc: Allocations will be placed on 16 byte boundaries. GuardMalloc: - Some buffer overruns may not be noticed. GuardMalloc: - Applications using vector instructions (e.g., SSE or Altivec) should work. GuardMalloc: GuardMalloc version 18 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xb2f79e88 0x00044951 in PyObject_GetAttr (v=0xb2de7c50, name=0xb2de79c0) at Objects/object.c:1126 1126if (tp->tp_getattro != NULL) (gdb) info locals tp = (PyTypeObject *) 0xb2f79e40 v = (PyObject *) 0xb2de7c50 name = (PyObject *) 0xb2de79c0 (gdb) print tp->tp_getattro Cannot access memory at address 0xb2f79e88 (gdb) bt #0 0x00044951 in PyObject_GetAttr (v=0xb2de7c50, name=0xb2de79c0) at Objects/object.c:1126 #1 0x00099409 in PyEval_EvalFrameEx (f=0xb31fdeb0, throwflag=0) at Python/ceval.c:1990 #2 0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, globals=0xb002fd20, locals=0x0, args=0xb2dee8fc, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2836 #3 0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2dee8f0, kw=0x0) at Objects/funcobject.c:517 #4 0x8b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) at Objects/abstract.c:1861 #5 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, name=0xb2de79c0) at Objects/typeobject.c:4775 #6 0x00099409 in PyEval_EvalFrameEx (f=0xb31fbeb0, throwflag=0) at Python/ceval.c:1990 #7 0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, globals=0xb002fd20, locals=0x0, args=0xb2dee8d4, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2836 #8 0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2dee8c8, kw=0x0) at Objects/funcobject.c:517 #9 0x8b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) at Objects/abstract.c:1861 #10 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, name=0xb2de79c0) at Objects/typeobject.c:4775 #11 0x00099409 in PyEval_EvalFrameEx (f=0xb31f9eb0, throwflag=0) at Python/ceval.c:1990 #12 0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, globals=0xb002fd20, locals=0x0, args=0xb2dee8ac, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2836 #13 0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2dee8a0, kw=0x0) at Objects/funcobject.c:517 #14 0x8b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) at Objects/abstract.c:1861 #15 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, name=0xb2de79c0) at Objects/typeobject.c:4775 #16 0x00099409 in PyEval_EvalFrameEx (f=0xb31f7eb0, throwflag=0) at Python/ceval.c:1990 #17 0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, globals=0xb002fd20, locals=0x0, args=0xb2dee884, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2836 #18 0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2dee878, kw=0x0) at Objects/funcobject.c:517 #19 0x8b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) at Objects/abstract.c:1861 #20 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, name=0xb2de79c0) at Objects/typeobject.c:4775 [...] #1554 0x8b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) at Objects/abstract.c:1861 #1555 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, name=0xb2de79c0) at Objects/typeobject.c:4775 #1556 0x00099409 in PyEval_EvalFrameEx (f=0xb2f8beb0, throwflag=0) at Python/ceval.c:1990 #1557 0x0009f29a in PyEval_EvalCodeEx (co=0xb060ef50, globals=0xb002fd20, locals=0x0, args=0xb2de967c, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2836 #1558 0x0002c8ea in function_call (func=0xb0623cf0, arg=0xb2de9670, kw=0x0) at Objects/funcobject.c:517 #1559 0x8b07 in PyObject_CallFunctionObjArgs (callable=0xb0623cf0) at Objects/abstract.c:1861 #1560 0x00068e05 in slot_tp_getattr_hook (self=0xb2de7c50, name=0xb060d5c0) at Objects/typeobject.c:4775 #1561 0x00044a66 in PyObject_GetAttrString (v=0xb2de7c50, name=0xed255) at Objects/o
[issue3242] Segfault in PyFile_SoftSpace/PyEval_EvalFrameEx with sys.stdout reassigned
Brodie Rao <[EMAIL PROTECTED]> added the comment: Thanks. The patch fixes the crash for me on Python 2.5.2 and 2.6b1 on OS X and Python 2.4.5 on Debian and Ubuntu. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3242> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3684] traceback.format_exception_only() misplaces the caret for certain SyntaxErrors
New submission from Brodie Rao <[EMAIL PROTECTED]>:
>> +
File "", line 1
+
^
SyntaxError: invalid syntax
>>> import sys
>>> import traceback
>>> traceback.print_exception(sys.last_type, sys.last_value, None)
File "", line 1
+
^
SyntaxError: invalid syntax
>>> sys.last_value
SyntaxError('invalid syntax', ('', 1, 2, '+\n'))
print_error_text() effectively ignores trailing newlines when placing
the caret, while traceback.format_exception_only() does not. For certain
syntax errors the offset reported is sometimes at the newline, as in the
case of a line of code that ends just with a plus sign (and in other
similar cases).
I'm attaching a patch for trunk that fixes this issue. I know it also
affects Python 2.5, and I'm sure it affects versions prior. I don't know
about Python 3.0.
--
components: Library (Lib)
files: traceback-caret.patch
keywords: patch
messages: 71967
nosy: brodierao
severity: normal
status: open
title: traceback.format_exception_only() misplaces the caret for certain
SyntaxErrors
type: behavior
Added file: http://bugs.python.org/file11260/traceback-caret.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3684>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4050] inspect.findsource() returns binary data for shared library modules
New submission from Brodie Rao <[EMAIL PROTECTED]>: Calling inspect.findsource() on a module whose __file__ attribute points to a shared library causes findsource() to return the binary's data: >>> import time >>> time.__file__ '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ lib-dynload/time.so' >>> import inspect >>> inspect.findsource(time) (['\xca\xfe\xba\xbe\x00\x00\x00\x04\x00\x00\x00\x12\x00\x00\x00\n', '\x00\x00\x10\x00\x00\x00Jt\x00... It should raise an error saying it can't retrieve the source. It doesn't do this because when it tries to find the source file it calls both getsourcefile() - and getfile() when that fails. It should call only getsourcefile() - which checks to see if __file__ points to a binary - and if the result is None, raise an error. I'm attaching a patch against trunk that fixes this. The issue affects 3.0, 2.6, 2.5, and probably previous versions. -- components: Library (Lib) files: inspect-findsource-binary.diff keywords: patch messages: 74358 nosy: brodierao severity: normal status: open title: inspect.findsource() returns binary data for shared library modules type: behavior versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file11706/inspect-findsource-binary.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4050> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2476] optparse docs should mention %default being new in 2.4
New submission from Brodie Rao <[EMAIL PROTECTED]>: The %default option help string feature doesn't exist in Python 2.3, but the documentation for Python 2.4 and 2.5 don't mention that it was added in 2.4. It should mention this so people developing for 2.3 and 2.4/2.5 can be aware of this. http://docs.python.org/lib/optparse-generating-help.html is the page describing the %default feature. I would imagine the bullet point about the feature being prefixed with "New in 2.4: ..." -- assignee: georg.brandl components: Documentation messages: 64450 nosy: brodierao, georg.brandl severity: normal status: open title: optparse docs should mention %default being new in 2.4 type: feature request versions: Python 2.4, Python 2.5, Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2476> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19338] multiprocessing: sys.exit() from a child with a non-int exit code exits with 0
New submission from Brodie Rao:
Normally:
$ python
>>> import sys
>>> sys.exit('foo')
foo
$ echo $?
1
However, with multiprocessing:
>>> import sys
>>> from multiprocessing import Process
>>> p = Process(target=lambda: sys.exit('foo'))
>>> p.start()
>>> foo
>>> p.join()
>>> p.is_alive()
False
>>> p.exitcode
0
p.exitcode should be 1, not 0. sys.exit() with a non-int object should always
exit with 1.
This regression was introduced in da5b370f41a1 on the 2.7 branch (making it
into the 2.7.4 release) and 4346cba353b4 on the 3.2 branch (making it into the
3.2.5 release).
Less important things to note:
- multiprocessing calls str() on the object passed to sys.exit() to print it
out. The interpreter doesn't do that with the argument is a unicode object (it
tries to let sys.stderr encode it and print it).
- The interpreter also ignores all exceptions in this process.
I'll attach patches for the 2.7 and 3.3 branches that just addresses the exit
code problem.
--
components: Library (Lib)
messages: 200833
nosy: brodie
priority: normal
severity: normal
status: open
title: multiprocessing: sys.exit() from a child with a non-int exit code exits
with 0
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue19338>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19338] multiprocessing: sys.exit() from a child with a non-int exit code exits with 0
Changes by Brodie Rao : Added file: http://bugs.python.org/file32287/multiprocessing-sys-exit-2.7.patch ___ Python tracker <http://bugs.python.org/issue19338> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19338] multiprocessing: sys.exit() from a child with a non-int exit code exits with 0
Brodie Rao added the comment: Here's the patch for 3.3. -- keywords: +patch Added file: http://bugs.python.org/file32286/multiprocessing-sys-exit-3.3.patch ___ Python tracker <http://bugs.python.org/issue19338> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19338] multiprocessing: sys.exit() from a child with a non-int exit code exits with 0
Changes by Brodie Rao : -- nosy: +jnoller, sbt ___ Python tracker <http://bugs.python.org/issue19338> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Changes by Brodie Rao : -- nosy: +brodie ___ Python tracker <http://bugs.python.org/issue6154> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
