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 port
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
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
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
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 defaul
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
