[issue25687] Error during test case and tearDown
New submission from Benno Leslie: I'm not sure if this should be considered a bug, but the behaviour is surprising and not clearly documented. I a have a very simple test that has an error during both the test case, and during tearDown. """ import unittest class Test(unittest.TestCase): def test_a(self): asdf def tearDown(self): asdf if __name__ == '__main__': unittest.main() """ When this occurs it is surprising (to me) that the output is: """ Ran 1 test in 0.000s FAILED (errors=2) """ In particular, the fact that has more errors than there are tests that have been run. Obviously in this very simple example it is clear what has happened, however in a test suite that has hundreds of test cases it is somewhat frustrating to have the number of failing test cases over-reported. (And of course in the real-world test suite that led to this the tearDown doesn't fail on every single test case like in this simplified example). Although there are definitely two errors occurring in my example, in all other cases, only the first error would be reported. e.g.: an error in setUp wouldn't run the test case, and only the first (potential) error in the testcase itself would occur. I think that either: 1/ The documentation of the tearDown method should clearly indicate that an error in tearDown would cause multiple errors to be reported for the single testCase, or. 2/ Change the implementation so that if there is an exception during tearDown, and there was already an error in the test case only the first error is reported. 2 is probably a non-starter given backwards compatibility concerns (even assuming anyone else thinks this is the best behaviour in this corner case). I'd be happy to try and draft something for #1 if that is the best action. -- components: Library (Lib) messages: 255045 nosy: bennoleslie priority: normal severity: normal status: open title: Error during test case and tearDown type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue25687> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24450] Add gi_yieldfrom calculated property to generator object
Benno Leslie added the comment: I've tried to address all the issues raised in the review of the first patch. -- Added file: http://bugs.python.org/file39725/gi_yieldfrom.v1.patch ___ Python tracker <http://bugs.python.org/issue24450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24450] Add gi_yieldfrom calculated property to generator object
Benno Leslie added the comment: Attached is my first attempt at implementing this feature. It includes to implementation, updates to documentation, and added test cases. I'm not a regular contributor so look forward to any feedback on improving the patch. -- keywords: +patch Added file: http://bugs.python.org/file39706/gi_yieldfrom.v0.patch ___ Python tracker <http://bugs.python.org/issue24450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24450] Add gi_yieldfrom calculated property to generator object
New submission from Benno Leslie: When a co-routine has delegated computation to another co-routine via "yield from", it is useful to be able to access the delegated-to co-routine. This proposed enhancement would add a new calculated property to the generator object called "gi_yieldfrom", which returns the delegated-to co-routine (or None). -- components: Interpreter Core messages: 245338 nosy: bennoleslie priority: normal severity: normal status: open title: Add gi_yieldfrom calculated property to generator object type: enhancement versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue24450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16866] libainstall doesn't create $(BINDIR) directory
Benno Leslie added the comment: In a similar manner the bininstall target relies on $(LIBPC), but does not create that. This makes me consider if the libainstall target should be installing pkg-config sciprt at all (and whether bininstall should be installing the .pc files). It is hard for me to determine what the exact intended goals of each of these targets is, so I can't really come up with the right fix. Naively for both targets ensuring that the directory exists solves the symptom, but to be it looks like there is probably a greater underlying thing to determine here. -- ___ Python tracker <http://bugs.python.org/issue16866> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16869] makesetup should support .S source files
Benno Leslie added the comment: Thanks for the comments Senthil. I'll improve the patch fixing the bug, adding support for .s and updating the docs. -- ___ Python tracker <http://bugs.python.org/issue16869> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16866] libainstall doesn't create $(BINDIR) directory
Benno Leslie added the comment: I was using this in the case where I just want to link against libpython.a and for me it is a limited case where I don't really need the functionality of python-config; so for me this is certainly the best approach. But I concede this use case is probably a very little general interest. If the goal is to have a working python-config, then I guess libainstall should depend on bininstall. I'm not too fussed which approach is taken, I just think that (make && make libainstall) should work. I'm happy to fashion a patch for whichever approach is thought to be best. -- ___ Python tracker <http://bugs.python.org/issue16866> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16869] makesetup should support .S source files
New submission from Benno Leslie: It is useful to be able to build .S files as built-in modules (in particular if you want ctypes as a built-in you need .S files) The patch enables .S files to be specified in Setup.dist files. -- components: Build files: makesetup-asm.diff keywords: patch messages: 179111 nosy: bennoleslie priority: normal severity: normal status: open title: makesetup should support .S source files versions: Python 3.4 Added file: http://bugs.python.org/file28574/makesetup-asm.diff ___ Python tracker <http://bugs.python.org/issue16869> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16867] setup.py fails if there are no extensions
New submission from Benno Leslie: When building if there are zero extensions setup.py fails (max of a zero length list is undefined.) Although not a very common case, there are potential speciality cases where there will be zero extensions. -- components: Build files: zero_length_extensions.diff keywords: patch messages: 179104 nosy: bennoleslie priority: normal severity: normal status: open title: setup.py fails if there are no extensions versions: Python 3.4 Added file: http://bugs.python.org/file28570/zero_length_extensions.diff ___ Python tracker <http://bugs.python.org/issue16867> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16866] libainstall doesn't create $(BINDIR) directory
Changes by Benno Leslie : -- title: libainstall doesn't create all directories -> libainstall doesn't create $(BINDIR) directory ___ Python tracker <http://bugs.python.org/issue16866> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16866] libainstall doesn't create all directories
New submission from Benno Leslie: make libainstall fails when $(BINDIR) does not exist. -- components: Build files: ainstall.diff keywords: patch messages: 179103 nosy: bennoleslie priority: normal severity: normal status: open title: libainstall doesn't create all directories type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file28569/ainstall.diff ___ Python tracker <http://bugs.python.org/issue16866> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16833] httpc.lient delayed ack / Nagle algorithm optimisation performs badly for large messages
Benno Leslie added the comment: I've updated the patch based on Charles-François and Antoine's feedback. Primarily this increase the estimated MSS value to 16KiB. Additionally tests are added and comments improved. Thanks for the feedback. -- Added file: http://bugs.python.org/file28521/http_opt_v2.diff ___ Python tracker <http://bugs.python.org/issue16833> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16833] httpc.lient delayed ack / Nagle algorithm optimisation performs badly for large messages
New submission from Benno Leslie: he http.client HTTPConnection._send_output method has an optimization for avoiding bad interactions between delayed-ack and the Nagle algorithm: http://hg.python.org/cpython/file/f32f67d26035/Lib/http/client.py#l884 Unfortunately this interacts rather poorly if the case where the message_body is a bytes instance and is rather large. If the message_body is bytes it is appended to the headers, which causes a copy of the data. When message_body is large this duplication of data can cause a significant spike in memory usage. (In my particular case I was uploading a 200MB file to 30 hosts at the same leading to memory spikes over 6GB. [There is a short thread discussing this issue on python-dev; Subject: "http.client Nagle/delayed-ack optimization"; Date: Dec 15, 2012] -- components: Library (Lib) files: http_opt.diff keywords: patch messages: 178728 nosy: bennoleslie priority: normal severity: normal status: open title: httpc.lient delayed ack / Nagle algorithm optimisation performs badly for large messages type: performance versions: Python 3.3 Added file: http://bugs.python.org/file28518/http_opt.diff ___ Python tracker <http://bugs.python.org/issue16833> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16140] subprocess.Popen the os.close calls in _execute_child can raise an EBADF exception
Benno Leslie added the comment: Regarding #2 my understanding is that the FDs are already always wrapped. E.g: at line http://hg.python.org/cpython/file/b9ac3c44a4eb/Lib/subprocess.py#l798 it shows these always being wrapped (assuming the file descriptor is not -1). For my test case on 3.2.3, replacing the os.close loop with: if p2cwrite != -1: self.stdin.close() if c2pread != -1: self.stdout.close() if errread != -1: self.stderr.close() This fixed all my stability problems and races, and can't (as far as I can tell) cause any other problems; however this is a very subtle module, so I'm eager to understand if this would cause any undesirable side-effects. -- ___ Python tracker <http://bugs.python.org/issue16140> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16140] subprocess.Popen the os.close calls in _execute_child can raise an EBADF exception
Changes by Benno Leslie : -- nosy: +bennoleslie ___ Python tracker <http://bugs.python.org/issue16140> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
