[issue45924] Incorrect traceback when future's exception is raised multiple times

Change by lilydjwg : -- nosy: +lilydjwg ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45924] Incorrect traceback when future's exception is raised multiple times

Irit Katriel added the comment: Closed issue42682 as duplicate of this. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue45924] Incorrect traceback when future's exception is raised multiple times

Irit Katriel added the comment: Closed issue46954 as a duplicate of this. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue45924] Incorrect traceback when future's exception is raised multiple times

Change by Kumar Aditya : -- keywords: +patch nosy: +kumaraditya303 nosy_count: 5.0 -> 6.0 pull_requests: +28489 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/30274 ___ Python tracker

[issue45924] Incorrect traceback when future's exception is raised multiple times

Vishal Pandey added the comment: thanks, It was my mistake, bug reproduced. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue45924] Incorrect traceback when future's exception is raised multiple times

Irit Katriel added the comment: Vishal, your output shows you’re running 3.8, not 3.10. traceback.print_exception() used to require 3 parameters, now it can make do with just one. See the docs for the details. -- ___ Python tracker

[issue45924] Incorrect traceback when future's exception is raised multiple times

Vishal Pandey added the comment: hey Irit, Is this issue platform-dependent? I am on ubuntu 20.04, and running python 3.10. I am not getting the same error that you have mentioned below. This is what I am getting. ### hello ... Traceback (most recent call

[issue45924] Incorrect traceback when future's exception is raised multiple times

Guido van Rossum added the comment: There's a similar issue with concurrent.futures.Future, and really, anything that stores exceptions and later raises them can get in trouble if there's a way to get the exception raised multiple times. This is rarely noticed because usually the exception

[issue45924] Incorrect traceback when future's exception is raised multiple times

Change by Irit Katriel : -- pull_requests: -28067 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45924] Incorrect traceback when future's exception is raised multiple times

Change by Irit Katriel : -- keywords: +patch pull_requests: +28067 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29780 ___ Python tracker ___

[issue45924] Incorrect traceback when future's exception is raised multiple times

normal status: open title: Incorrect traceback when future's exception is raised multiple times type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45924> ___ __

[issue43596] change assertRaises message when wrong exception is raised

Irit Katriel added the comment: I agree. That’s what the “usually” was for. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue43596] change assertRaises message when wrong exception is raised

, or vice versa, you'd like the test to tell you that the wrong exception type was raised. I've definitely done this myself on more than a few occasions. So this *particular* case is an exception to Irit's observation that "The two problems are usually unrelated [...]". But I think it *is* an

[issue43596] change assertRaises message when wrong exception is raised

Serhiy Storchaka added the comment: I concur with Irit. The test is failed in any case, so you need to look at the code to fix it. For the same reason we do not have assertNotRaises(). -- nosy: +serhiy.storchaka ___ Python tracker

[issue43596] change assertRaises message when wrong exception is raised

Irit Katriel added the comment: Another way to look at it is that your test has two problems. One is that the expected exception didn’t happen and the other is that an unexpected exception happened. The two problems are usually unrelated, and trying to conflate them into one error message

[issue43596] change assertRaises message when wrong exception is raised

Change by Irit Katriel : -- components: +Library (Lib) ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43596] change assertRaises message when wrong exception is raised

Irit Katriel added the comment: What you are suggesting replaces the type of the exception being raised. If it's something like a MemoryError or KeyboardInterrupt you don't want that, you want your test process to terminate. -- nosy: +iritkatriel

[issue43728] Change the exception message raised when _curses is not found.

Eric V. Smith added the comment: @shreyanavigyan: Thank you for your efforts to improve Python! -- resolution: -> wont fix ___ Python tracker ___

[issue43728] Change the exception message raised when _curses is not found.

Change by Shreyan Avigyan : -- stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue43728] Change the exception message raised when _curses is not found.

Shreyan Avigyan added the comment: Yeah...I agree. Therefore this issue is resolved and I will close this issue now. Thanks everyone for the advice. With Regards -- ___ Python tracker

[issue43728] Change the exception message raised when _curses is not found.

Eric V. Smith added the comment: I agree with Ned. This is why I'm not sure it’s worth changing the message: googling gives good information, and the exact thing to do in order resolve this (if it’s even possible) is dependent on a number of factors that the code raising the exception can’t

[issue43728] Change the exception message raised when _curses is not found.

Ned Deily added the comment: "Install a supported _curses library" That's not correct advice. _curses is the name of the support module written in C in the Python Standard Library. If it is not available to import in an installation, it's most likely because the build of the module failed

[issue43728] Change the exception message raised when _curses is not found.

Shreyan Avigyan added the comment: Is this issue ready for a PR? -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue43728] Change the exception message raised when _curses is not found.

Change by Shreyan Avigyan : -- title: Change the exception type and message raised when _curses is not found. -> Change the exception message raised when _curses is not found. ___ Python tracker <https://bugs.python.org/issu

[issue43596] change assertRaises message when wrong exception is raised

Change by Kamil Turek : -- nosy: +kamilturek ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43596] change assertRaises message when wrong exception is raised

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43596] change assertRaises message when wrong exception is raised

Change by Nathaniel Manista : -- nosy: +Nathaniel Manista ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43596] change assertRaises message when wrong exception is raised

erity: normal status: open title: change assertRaises message when wrong exception is raised ___ Python tracker <https://bugs.python.org/issue43596> ___ ___ Python-bugs-lis

[issue39101] IsolatedAsyncioTestCase freezes when exception is raised

miss-islington added the comment: New changeset 9d409d6b474c188feca6213b9601e06f97715b72 by Miss Islington (bot) in branch '3.9': bpo-39101: Fixes BaseException hang in IsolatedAsyncioTestCase. (GH-22654) https://github.com/python/cpython/commit/9d409d6b474c188feca6213b9601e06f97715b72

[issue39101] IsolatedAsyncioTestCase freezes when exception is raised

miss-islington added the comment: New changeset d549d0b5575b390431b7b26999151f79f74d4516 by Miss Islington (bot) in branch '3.8': bpo-39101: Fixes BaseException hang in IsolatedAsyncioTestCase. (GH-22654) https://github.com/python/cpython/commit/d549d0b5575b390431b7b26999151f79f74d4516

[issue39101] IsolatedAsyncioTestCase freezes when exception is raised

Change by Lisa Roach : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue39101] IsolatedAsyncioTestCase freezes when exception is raised

Lisa Roach added the comment: New changeset 8374d2ee1589791be8892b00f4bbf8121dde24bd by Lisa Roach in branch 'master': bpo-39101: Fixes BaseException hang in IsolatedAsyncioTestCase. (GH-22654) https://github.com/python/cpython/commit/8374d2ee1589791be8892b00f4bbf8121dde24bd --

[issue39101] IsolatedAsyncioTestCase freezes when exception is raised

Change by miss-islington : -- pull_requests: +21904 pull_request: https://github.com/python/cpython/pull/22989 ___ Python tracker ___

[issue39101] IsolatedAsyncioTestCase freezes when exception is raised

Change by miss-islington : -- nosy: +miss-islington nosy_count: 4.0 -> 5.0 pull_requests: +21903 pull_request: https://github.com/python/cpython/pull/22988 ___ Python tracker

[issue39101] IsolatedAsyncioTestCase freezes when exception is raised

Change by Lisa Roach : -- keywords: +patch nosy: +lisroach nosy_count: 3.0 -> 4.0 pull_requests: +21630 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22654 ___ Python tracker

[issue36284] importlib.import_module() not thread safe if Exception is raised (3.4, 3.5)

Brett Cannon added the comment: @Patrick you will have to open a new issue and be very specific about what the problem is with a reproducible code snippet to show how the current fix is wrong (I also don't know how upgrading Django comes into play since this is not Django's issue tracker).

[issue36284] importlib.import_module() not thread safe if Exception is raised (3.4, 3.5)

Patrick Thizy added the comment: I use Apache + mod_wsgi on Windows When I update from Django 2.2.4 to Django 2.2.5, this fix has been apply With this fix my application is not running The navigator is lock and waiting Can you help me ? -- nosy: +Patrick Thizy

[issue39101] IsolatedAsyncioTestCase freezes when exception is raised

Change by Fabio Pugliese Ornellas : -- type: -> crash ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39101] IsolatedAsyncioTestCase freezes when exception is raised

l status: open title: IsolatedAsyncioTestCase freezes when exception is raised versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39101> ___ ___ Python-bugs-lis

[issue36284] importlib.import_module() not thread safe if Exception is raised (3.4, 3.5)

Serhiy Storchaka added the comment: 3.4 and 3.5 take only security fixes. The only solution of this problem is upgrading to 3.6 or 3.7. -- nosy: +serhiy.storchaka resolution: -> out of date stage: -> resolved status: open -> closed ___ Python

[issue36284] importlib.import_module() not thread safe if Exception is raised (3.4, 3.5)

Change by Karthikeyan Singaravelan : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36284] importlib.import_module() not thread safe if Exception is raised (3.4, 3.5)

wing the code to continue it's normal execution. -- components: Library (Lib) messages: 337887 nosy: Riccardo Coccioli priority: normal severity: normal status: open title: importlib.import_module() not thread safe if Exception is raised (3.4, 3.5) type: behavior ve

[issue34786] ProcessPoolExecutor documentation reports wrong exception being raised

Change by Xiang Zhang : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue34786] ProcessPoolExecutor documentation reports wrong exception being raised

Change by miss-islington : -- pull_requests: +8957 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34786] ProcessPoolExecutor documentation reports wrong exception being raised

Karthikeyan Singaravelan added the comment: Got it. Sorry about that I copy pasted the quoted string and assumed ThreadPoolExecutor overlooking the PR. The change is reasonable to me. Thanks -- ___ Python tracker

[issue34786] ProcessPoolExecutor documentation reports wrong exception being raised

Joni Kähärä added the comment: Perhaps I wasn't clear that this considered ProcessPoolExecutor documentation, not ThreadPoolExecutor. Taking the example from documentation and adding an initializer like this: import concurrent.futures import math PRIMES = [ 112272535095293,

[issue34786] ProcessPoolExecutor documentation reports wrong exception being raised

Karthikeyan Singaravelan added the comment: I think it raises BrokenThreadPool . A sample program that I tried as below raising an exception in the initializer. Maybe I am wrong here. Can you please attach a script that triggers BrokenProcessPool? # bpo34786.py import concurrent.futures

[issue34786] ProcessPoolExecutor documentation reports wrong exception being raised

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34786] ProcessPoolExecutor documentation reports wrong exception being raised

Change by Roundup Robot : -- keywords: +patch pull_requests: +8936 stage: -> patch review ___ Python tracker ___ ___

[issue34786] ProcessPoolExecutor documentation reports wrong exception being raised

open title: ProcessPoolExecutor documentation reports wrong exception being raised versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34786> ___ ___

[issue18510] if Enum member value is not hashable an exception is raised

block, but I must admit I was surprised the answer wasn't False. -- assignee: ethan.furman messages: 193384 nosy: ethan.furman priority: normal severity: normal status: open title: if Enum member value is not hashable an exception is raised type: behavior

[issue18510] if Enum member value is not hashable an exception is raised

Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18510 ___ ___ Python-bugs-list mailing

Re: Exception not raised - May be the end

Michele Petrazzo [EMAIL PROTECTED] wrote: some days ago I posted here and say that python forgot to raise an exception, but my code was too long for make some tries possible. But now I can reproduce the problem into another, little, project: www.unipex.it/vario/wxFrameSchedule.py

Re: Exception not raised - May be the end

Sion Arrowsmith wrote: Michele Petrazzo [EMAIL PROTECTED] wrote: some days ago I posted here and say that python forgot to raise an exception, but my code was too long for make some tries possible. But now I can reproduce the problem into another, little, project:

Exception not raised - May be the end

Hi group, some days ago I posted here and say that python forgot to raise an exception, but my code was too long for make some tries possible. But now I can reproduce the problem into another, little, project: (Need wx 2.6) Here is the code: www.unipex.it/vario/wxFrameSchedule.py

Re: Exception not raised

in-between doesn't propagate the exception for whatever reason? Can be, but only that exception aren't raised, all the other, in the same point of code, yes. Fact is: pythons exception-handling is core part of the language and an error in there _extremely_ improbable . I think the same

Exception not raised

So all the exception are raised except the KeyError outside the try/except! I don't know what can be. Thanks to all that can help me. Michele -- http://mail.python.org/mailman/listinfo/python-list

Re: Exception not raised

Michele Petrazzo wrote: Simple example extract from my code: #code def test(): print type(t_fields), 11 in t_fields print t_fields[11] print I'm here print ok test() print ok #end code Output: ok type 'dict' False Here I see only one ok and not the I'm here. The

Re: Exception not raised

print dont_exist NameError: global name 'dont_exist' is not defined So all the exception are raised except the KeyError outside the try/except! I don't know what can be. Thanks to all that can help me. Michele When I run your first example I get: type 'dict' False Traceback

Re: Exception not raised

Diez B. Roggisch wrote: Not here: t_fields = {} #code def test(): print type(t_fields), 11 in t_fields print t_fields[11] print I'm here print ok test() print ok #end code Gives me KeyError: 11 Also on my environ when I try this 4 line code. My project, where that

Re: Exception not raised

Michele Petrazzo wrote: Hi list, I have a strange error on my software on win 2k/xp and debian 3.1 with py 2.3.5 / 2.4.1 + twisted + wxpython: Just for give evidence to my _failed_ tests, my a debugger (eric3), it see the exception, so it break with a KeyError! And the same code, no! Thanks,

Re: Exception not raised

Michele Petrazzo wrote: Michele Petrazzo wrote: Hi list, I have a strange error on my software on win 2k/xp and debian 3.1 with py 2.3.5 / 2.4.1 + twisted + wxpython: Opss, I forgot some words :) Just for give evidence to my _failed_ tests, my a debugger (eric3), it with a debugger (not

Re: Exception not raised

This code are inside a method into class that have no try/except. And called from a method inside a wx.Frame derivate. The other strange thing is that if I try the same code just before the caller to that method, it raise an exception: So maybe the C-layer of wx in-between doesn't

pexpect: TIMEOUT exception never raised

series of 'y' characters to the terminal. I want to timeout after 10 seconds -: child=pexpect.spawn('ssh [EMAIL PROTECTED]') child.sendline('yes') child.expect([pexpect.TIMEOUT, the pattern I'm expecting],10) In this situation, pexpect.TIMEOUT will never be raised. The TIMEOUT exception is only

_conditionally_ returning to point where exception was raised?

-time) whether or not the execution of the called method resumes. Until now I only see two possibilities: either the caller is coded in a way that it handles the exception and execution of the called method resumes at the point where the exception was raised or the caller was written in a way

Re: _conditionally_ returning to point where exception was raised?

There's no Resume Next in python. Once you catch an exception, the only way you can go is forward from that point. So if B.CallingMethod catches an exception that was raised in A.CalledMethod, all it could do is try calling A.CalledMethod again, it can't jump back to the point where

Re: _conditionally_ returning to point where exception was raised?

the exception was raised or the caller was written in a way that doesn't handle it and the program is stopped by the interpreter. Is there a third way, ie is it possible to determine at run-time whether the called method is resumed? Thanks in advance, Once an exception is raised, the stack gets

Re: _conditionally_ returning to point where exception was raised?

an exception is raised, the stack gets unwound to the point Bengt where the exception is caught, so there is no way[1] to recover Bengt the context required to continue (and eventually return Bengt normally as if the exception hadn't happened). I suspect in the OP's case if A.CalledMethod

Re: How to test that an exception is raised ?

Op 2005-01-28, StepH schreef [EMAIL PROTECTED]: Antoon Pardon a écrit : Op 2005-01-28, StepH schreef [EMAIL PROTECTED]: Thanks for you answer. I'm new to Python (coming from C/C++). Do you say that it's not possible to test (using unittest) if an exception is well raised if the tested code

How to test that an exception is raised ?

(self): Check that an exception is raised if a bad filename is passed to mps2xml self.assertRaises((IOError),mps2xml.mps2xml, thisfiledoesntexists, False) def test_writeVar_Output(self): Check the output of the 'writeVar' method line = irM1slotnoisePPtmp Var

Re: How to test that an exception is raised ?

[snipped alot of codes that doesn't mean much ] if you want to check for exception then it goes like this try: put your code here which fails on certain exception like maybe IOError catch IOError: put a code to do something when IOError is raised sorry i won't bother to read your code because

Re: How to test that an exception is raised ?

StepH [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] But i've prob with the 1st test : test_badFile. When I run the test, unittest say that no error is Raised. But when I run the mps2xml module with a bad file as arg., the exception is well Raised. I assume you don't actually

Re: How to test that an exception is raised ?

Thanks for you answer. I'm new to Python (coming from C/C++). But i've prob with the 1st test : test_badFile. When I run the test, unittest say that no error is Raised. But when I run the mps2xml module with a bad file as arg., the exception is well Raised. I assume you don't actually

Re: How to test that an exception is raised ?

StepH [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Do you say that it's not possible to test (using unittest) if an exception is well raised if the tested code catch it ? How to solve this paradoxe ? How to automaticaly test such code ? Then you need a side-effect in catching

Re: How to test that an exception is raised ?

Antoon Pardon a écrit : Op 2005-01-28, StepH schreef [EMAIL PROTECTED]: Thanks for you answer. I'm new to Python (coming from C/C++). Do you say that it's not possible to test (using unittest) if an exception is well raised if the tested code catch it ? How to solve this paradoxe ? How

Re: How to test that an exception is raised ?

StepH [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] So why the assertRaises function in unittest ? My goal is to test if an exception is well raised when a bad filename is passed to the mps2xml function. It is for functions in which the exception is raised and not caught. You