Why doesn't threading.join() return a value?

[Roy Smith]

In article 
<5da6bf87-9412-46c4-ad32-f8337d56b2c3 at o15g2000vbe.googlegroups.com>,
 Adam Skutt <askutt at gmail.com> wrote:

> On Sep 2, 10:53 am, Roy Smith <r... at panix.com> wrote:
> > I have a function I want to run in a thread and return a value.  It
> > seems like the most obvious way to do this is to have my target
> > function return the value, the Thread object stash that someplace, and
> > return it as the return value for join().
> > > Yes, I know there's other ways for a thread to return values (pass the
> > target a queue, for example), but making the return value of the
> > target function available would have been the most convenient.  I'm
> > curious why threading wasn't implemented this way.
> 
> I assume it is because the underlying operating system APIs do not
> support it.  Windows and POSIX threads only support returning an
> integer when a thread exits, similar to the exit code of a process.

But the whole point of higher level languages is to hide the warts of 
the lower-level APIs they are built on top of.  Just because a POSIX 
thread can only return an int (actually, a void *) doesn't mean that 
level of detail needed to be exposed at the Python threading library 
level.

> More importantly, there's no way to tell whether the exit code of a
> thread was set by user code or by the system.  Even worse, some of
> those integer values are reserved by some operating systems.  If your
> thread died via an exception, it still has an error code set by the
> operating system.  How would you going to distinguish those codes from
> your own?

I think you're talking about processes, not threads, but in any case, 
it's a non-sequitur.  Thread.join() currently returns None, so there's 
no chance for confusion.