[issue24948] Multiprocessing not timely flushing stack trace to stderr

Changes by Jon Brandvein : -- nosy: +brandjon ___ Python tracker <http://bugs.python.org/issue24948> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue21366] Document that return in finally overwrites prev value

New submission from Jon Brandvein: def foo(): try: return 1 finally; return 2 print(foo()) # 2 I've seen this peculiar case discussed on a few blogs lately, but was unable to find confirmation that this behavior is defined. In the try/finally section of Doc/refe

[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator

Changes by Jon Brandvein : -- nosy: +brandj ___ Python tracker <http://bugs.python.org/issue4806> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10482] subprocess and deadlock avoidance

Changes by Jon Brandvein : -- nosy: +brandj ___ Python tracker <http://bugs.python.org/issue10482> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13854] multiprocessing: SystemExit from child with non-int, non-str arg causes TypeError

Jon Brandvein added the comment: Also, as Brett pointed out to me in #13853, bool is a subclass of int, so they should follow the same code path. I suggest replacing elif type(e.args[0]) is int: exitcode = e.args[0] with something like elif isinstance(e.args[0], int

[issue13857] Add textwrap.indent() as counterpart to textwrap.dedent()

Jon Brandvein added the comment: > If such a function is added, I'd like the option to not indent empty lines: > trailing spaces are often not a good idea. >From dedent's documentation, it wasn't immediately clear to me that it ignores >blank lines when determi

[issue13854] multiprocessing: SystemExit from child with non-int, non-str arg causes TypeError

New submission from Jon Brandvein : In a child process, raising SystemExit or calling sys.exit with a non-integer, non-string argument value causes a TypeError at Lib/multiprocessing/process.py :: _bootstrap. This is from concatenating the argument with '\n' and writing it

[issue13853] SystemExit/sys.exit() doesn't print boolean argument

New submission from Jon Brandvein : Raising SystemExit manually, or calling sys.exit, with an argument of "True" or "False" results in no output to the screen. According to Doc/library/exceptions.rst and Doc/library/sys.rst, any object that is not an integer or None

[issue13841] multiprocessing should use sys.exit() where possible

Jon Brandvein added the comment: Good point. I don't think those particular behaviors are documented, so I'm not sure whether we need to worry about breaking them. -- ___ Python tracker <http://bugs.python.o

[issue13812] multiprocessing package doesn't flush stderr on child exception

Jon Brandvein added the comment: Patch looks fine. I like the use of "finally" for the flush. -- ___ Python tracker <http://bugs.python.org/issue13812> ___ __

[issue13841] multiprocessing should use sys.exit() where possible

New submission from Jon Brandvein : Currently the multiprocessing library calls a hard exit function (os._exit under unix, ExitProcess under Windows) to terminate the child process. Under unix, this is necessary because the child is forked without exec-ing. Calling sys.exit() would make it

[issue13812] multiprocessing package doesn't flush stderr on child exception

Jon Brandvein added the comment: Regarding the patch: I'd also like to see sys.stdout.flush() and sys.stderr.flush() between "exitcode = self._boostrap()" and "exit(exitcode)" in /Lib/multiprocessing/forking.py :: main(). (The extra stderr flush would be for sym

[issue13812] multiprocessing package doesn't flush stderr on child exception

Jon Brandvein added the comment: It turns out the file output was flushing due to garbage collection. When I created and held a global reference to it, it ceased to flush. Clearly, reassigning sys.stdout also held a reference to it. So it wasn't any kind of special sys.stdout-specific

[issue13812] multiprocessing package doesn't flush stderr on child exception

Jon Brandvein added the comment: Some more information: When I write to a new file created by open(), all versions flush correctly. However, if I reassign sys.stdout to that file, Python 3.x does not (again, under Windows). I wonder what it is that causes these other files to flush. (Note

[issue13812] multiprocessing package doesn't flush stderr on child exception

Jon Brandvein added the comment: I've been looking over this package some more, and in particular, /Lib/multiprocessing/forking.py. There's plenty I don't understand, and I do have questions, if you would be willing to indulge me. I see that both the unix and windows code

[issue13812] multiprocessing package doesn't flush stderr on child exception

Jon Brandvein added the comment: On Windows, the problem appears under Python 3.2.2 and 3.1.3, but not under 2.7.1. On Linux, I have not reproduced the problem on versions 2.6.3, 2.7.2, 3.1.1, or 3.2.2. So to summarize: - It seems there should be a stderr flush call on the line I

[issue13812] multiprocessing package doesn't flush stderr on child exception

Jon Brandvein added the comment: (Er, that should be /Lib/multiprocessing/process.py :: Process._bootstrap of course.) -- ___ Python tracker <http://bugs.python.org/issue13

[issue13812] multiprocessing package doesn't flush stderr on child exception

New submission from Jon Brandvein : When a child process exits due to an exception, a traceback is written, but stderr is not flushed. Thus I see a header like "Process 1:\n", but no traceback. I don't have a development environment or any experience with Mecurial, so I'