[issue36666] threading.Thread should have way to catch an exception thrown within
Joel Croteau added the comment: I'm kind of in agreement with Mark on this, actually. I came across this problem when examining some threaded code that was clearly not working as intended, but was reporting success. Figuring out why that was was not easy. The code had been hastily ported to a multi-threaded version from an iterative version by my predecessor, and neither of us had enough familiarity with Python threads to realize what the problem was. The whole point of having exceptions is that it gives you a way of knowing when errors happen without having to add a bunch of extra error checking to your own code. It rather defeats the purpose if code can silently fail while still throwing exceptions, and we have to add extra code to handle special cases like this where they are ignored. -- ___ Python tracker <https://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36717] Allow retrieval of return value from the target of a threading.Thread
New submission from Joel Croteau : It would be nice if, after a threading.Thread has completed its run, it were possible to retrieve the return value of the target function. You can do this currently by setting a variable from your target or by subclassing Thread, but this should really be built in. My suggested changes: * Add an attribute to Thread, retval, initially set to None, that contains the return value of the target after a successful completion. * Thread.run() should set self.retval to the return value of the target upon completion, and also return this value. * Thread.join() should return self.retval after a successful completion. If you're not using Thread.join(), you can directly access Thread.retval to get the return result after a successful run. Thread.run() and Thread.join() both return None in all cases now, so I think a change in their return value would have minimal if any effect on existing code. -- components: Library (Lib) messages: 340815 nosy: Joel Croteau2 priority: normal severity: normal status: open title: Allow retrieval of return value from the target of a threading.Thread type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36666] threading.Thread should have way to catch an exception thrown within
Joel Croteau added the comment: Yes, I know there are workarounds for it, I have seen many, and everyone seems to have their own version. I'm saying we shouldn't need workarounds though–this should be built in functionality. Ideally, dropping an exception should never be default behavior, but I understand not wanting to break existing code, that's why I'm saying add additional functionality to make these checks easier and not require hacky, un-pythonic wrappers and other methods to find out if your code actually worked. -- ___ Python tracker <https://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36666] threading.Thread should have way to catch an exception thrown within
Joel Croteau added the comment: I agree that we should not change the default behavior of Thread.join(), as that would break existing code, but there are plenty of other ways to do this. I see a couple of possibilities: 1. Add an option to the Thread constructor, something like raise_exc, that defaults to False, but when set to True, causes join() to raise any exceptions. 2. (Better, IMO) Add this option to the join() method instead. 3. Create a new method, join_with_exc(), that acts like join() but raises exceptions from the target. 4. (Should probably do this anyway, regardless of what else we do) Add a new method, check_exc(), that checks if any unhandled exceptions have occurred in the thread and returns and/or raises any that have. -- ___ Python tracker <https://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36666] threading.Thread should have way to catch an exception thrown within
New submission from Joel Croteau : This has been commented on numerous times by others (https://stackoverflow.com/questions/2829329/catch-a-threads-exception-in-the-caller-thread-in-python, http://benno.id.au/blog/2012/10/06/python-thread-exceptions, to name a few), but there is no in-built mechanism in threading to catch an unhandled exception thrown by a thread. The default behavior of dumping to stderr is completely useless for error handling in many scenarios. Solutions do exist, but I have yet to see one that is not exceptionally complicated. It seems like checking for exceptions should be a very basic part of any threading library. The simplest solution would be to just have the Thread store any unhandled exceptions and have them raised by Thread.join(). There could also be additional methods to check if exceptions were raised. -- components: Library (Lib) messages: 340520 nosy: Joel Croteau priority: normal severity: normal status: open title: threading.Thread should have way to catch an exception thrown within versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
New submission from Joel Croteau : I understand to a certain extent the logic in not allowing IPv4 octets that might ambiguously be octal, but in practice, it just seems like it creates additional parsing hassle needlessly. I have never in many years of working on many networked systems seen anyone use dotted octal format, it is actually specifically forbidden by RFC 3986 (https://tools.ietf.org/html/rfc3986#section-7.4), and it means that the ipaddress module throws exceptions on many perfectly valid IP addresses just because they have leading zeroes. Since the module doesn't support dotted octal or dotted hex anyway, this check seems a little pointless. If nothing else, there should be a way to disable this check by specifying that your IPs are in fact dotted decimal, otherwise it seems like it's just making you have to do extra parsing work or just write your own implementation. -- components: Library (Lib) messages: 338514 nosy: Joel Croteau priority: normal severity: normal status: open title: ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue36384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
