[Patches] [ python-Patches-731607 ] make threading join() method return a value

[SourceForge.net]

Patches item #731607, was opened at 2003-05-02 14:19
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470

Category: Library (Lib)
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Matthew Boedicker (mboedick)
Assigned to: Nobody/Anonymous (nobody)
Summary: make threading join() method return a value

Initial Comment:
This patch makes the join() method of a threading
module Thread return the value that was returned by the
callable that is running in the thread.

It came about because I needed to split a process into
a number of threads, join them all, and then check what
each of them returned before proceeding.

It against the current CVS tree, tested on Linux.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-05-16 16:15

Message:
Logged In: YES 
user_id=357491

Closing and rejecting.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-08 16:47

Message:
Logged In: YES 
user_id=357491

If no one else speaks up on this patch by May 15 I am going to close it and 
reject it.

----------------------------------------------------------------------

Comment By: Matthew Boedicker (mboedick)
Date: 2003-05-04 20:23

Message:
Logged In: YES 
user_id=119895

I wasn't subclassing Thread, just instantiating it and passing in a target.  I 
didn't think of writing a wrapper, but that would work for me.  I still think 
having join() return something that might be useful in some circumstances is 
better than having it return something which is always useless (None), and 
easier than dealing with Queues or wrappers.

Anyway, thanks for feedback.  I'll probably use the wrapper approach for 
now.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-04 17:22

Message:
Logged In: YES 
user_id=357491

But don't you have the requirement that the code know that it is running in a 
thread when you made your subclass of threading.thread?  And even if you 
didn't, why can't you just wrap the code to catch the return value and push it 
into the queue in a threading class?

I am not going to reject this patch, Matthew, until someone else with commit 
privs comes in and says they don't like the patch either, so no need to 
worry... yet.  =)

----------------------------------------------------------------------

Comment By: Matthew Boedicker (mboedick)
Date: 2003-05-04 17:03

Message:
Logged In: YES 
user_id=119895

The problem with using a Queue is that it requires whatever is running in the 
thread to be aware it is running in a thread.  It would force non-threaded 
programs using that method to deal with Queues.  With the patch, there 
would be a standard, intuitive way to return data to the caller that worked 
whether the method was running in a separate thread or not.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-02 14:35

Message:
Logged In: YES 
user_id=357491

I don't think this is truly necessary.  If you needed to
know what they would return just insert it into a Queue and
when the 'join' calls finish check the Queue to see what was
added.

It also deviates from Java's threading setup which
'threading' is based on.

I'm -1 on this patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=731607&group_id=5470