[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()
Mark Borgerding added the comment: @serhiy.storchaka Thanks for the link to issue25054 to clarify this change was not done solely for aesthetics. Hopefully that will mollify others like me who find their way to this discussion as they try to figure out why their code broke with a new version of python. I wish it had been done in a more staged and overt way, but that is just spitting in the wind at this point. Thanks for all your work, my gripe du jour notwithstanding. -- ___ Python tracker <https://bugs.python.org/issue32308> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32308] Replace empty matches adjacent to a previous non-empty match in re.sub()
Mark Borgerding added the comment: So third-party code was knowingly broken to satisfy an aesthetic notion that substitution should be more like iteration. Would not a FutureWarning have been a kinder way to stage this implementation? A foolish consistency, indeed. -- nosy: +Mark Borgerding ___ Python tracker <https://bugs.python.org/issue32308> ___ ___ 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
Mark Borgerding added the comment: I'm not trying to disrespect anyone: not users nor certainly Python developers. I have loved Python since I learned it in 2001. I was merely trying to respond to what seemed like an automatic rejection of changing legacy behavior. I certainly agree changes to default behavior should not be made lightly, but sometimes they *should* be made. This may be such a case: a) A user writing a thread function either consciously thinks about exceptions while they write function or they do not. Sure, we should always do the former; just like we should always eat our veggies and get lots of exercise, but b) If they *do* think about exceptions, they will either b.1) write exception handlers within that function, or b.2) rely on default behavior that simply prints out the exception string to stderr and lets the thread quietly die. c) If they did not explicitly think about exceptions while they wrote the function, they may have in the back of their mind the reasonable expectation that an exception will not be ignored. Changing `join()` to propagate unhandled exceptions would admittedly break b.2 code, but provides absolution for all sinners who have written case c. This is what I meant by, "I suspect there is more code that will be fixed by such a change than broken." I'll confess I only just now became aware of `threading.excepthook` added in python 3.8. Does it change this problem? -- Added file: https://bugs.python.org/file48686/ignored_thread_exc.py ___ 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
Mark Borgerding added the comment: @pitrou I don't necessarily agree that "current behavior can't be changed". One major selling point of exceptions is that they cannot be accidentally ignored. The exception is how the current threading.Thread ignores them. You are correct that changing Thread.join() so it propagates exceptions by default may break code that relies on the implicit behavior of a thread dying when the target/run method raises. I'd argue such code deserves to be broken -- "explicit is better than implicit". I suspect there is more code that will be fixed by such a change than broken. ------ nosy: +Mark Borgerding ___ 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
