Using bare Queue.Queue in an inter-process manner by
passing data is often tedious low-level style and
overkill and leads to non-cohesive style of coding.

Also threading up to now doesn't support a simply
framework for non-blocking call execution _with_
result/end - a frequent need in GUI programming and
easy load balancing for jerky resources.

The attachment contains 2 tools for that: CallQueue and
BackgroundCall. 

I think they fit well into the standard Python (2.5) lib.

The attachment is in the form of a standalone Python
module and can be tested directly, the 2 things can be
easily copied to the target modules Queue / threading.


Robert


PS: fast atomic list.append / list.pop(0) / obj.var=..
 assumed ; commented out use of Queue.Queue ;
threading/Queue should maybe last of all do paranoid
locking after all other stuff in the lib does so, in
case Python would really go towards CPU level
memory/time atoms, what in my opinion would destroy a
VHL language. In case, I missed something, Queue should
be uncommented.  of the bare list. (The tests in all my
apps raised no problems - I used that like tools since
years, just reshaped them a little for this posting)

Logged In: YES 
user_id=972995

->attachment (new version and diff): an update which addes
options for exception handling (which I needed recently) and
resolves one bug.

Logged In: YES 
user_id=341410

Place this in the Python cookbook over at activestate.com
and/or release it as a standalone module.

If it gets nontrivial community support, it may have a
chance at Python standard library inclusion.  As it stands,
it likely has exactly one user (you), no documentation, no
unittest test cases, and no chance of making it into the
standard library.

Suggested close of this patch.

Rejecting as suggested.