Both Connection and Pipe objects expose their underlying file
descriptors, which is useful for accessing them in an event-driven
manner.  However the higher-level Queue does not make the underlying
pipe available; to get at them you must access private member attributes
which is fragile.  It would be good to have a well-defined API for
accessing either the pipe objects or the underlying FDs.

Steve, I'm a little nervous about exposing the underlying Queue pipes in 
an official API simply due to the fact that it is an advanced use case, 
and we do want to keep the API simple, and relatively close to the core 
Queue implementation.

Do you have an example use-case/code? This will not be making it into 
python 2.6/3.0 - it will need to wait until 2.7 and 3.1 at very least.

Hi Jesse,

The use-case I had is mind is enabling asyncronous (i.e. select() style)
notification of data being available on the queue, which is more elegant
(and efficient) than polling with get().  Example code showing how this
works with GTK is available here:

http://haltcondition.net/?p=2319

I understand wanting to keep the API simple, however the underlying
posix-level file-descriptors for pipes and connections are already
exposed via fileno(); the actual API change would just be a matter of
changing '_reader' and '_writer' to 'reader' and 'writer' (implicitly
guaranteeing their consistency).

Would it help if I attached a patch showing the proposed change to the
module?  I realise the API is frozen now but it would be nice to have
this further down the line.

Can you please provide an example w.r.t to how you would handle the case 
where poll()/recv returns partial bytes of the object instead of a full 
object?

As soon as some bytes are signalled as being available one can simply do a normal get(). I don't really see the problem here?
Sure, the get() might not be completely non-blocking (especially if the transferred event is more than the size of a pipe-buffer) but I have a hard time seing that as a problem as that should be both rare and only last a short time.

My personal use-case is being able to efficiently wait for evens from different queues - using the standard api one currently can only do that by busy looping...

The biggest thing I see where you have to be careful here is some stomping herd phenomenon you will get into if you have multiple readers doing a poll().
Namely *all* off those processes will awake and run into .get() which isnt exactly nice, but thats hardly solvable on python level.

I look forward to this, or something similar. Inspiration can be taken from Golangs's select behaviour on channels.

select {
case i1 = <-c1:
	print("received ", i1, " from c1\n")
case c2 <- i2:
	print("sent ", i2, " to c2\n")

default:
	print("no communication\n")
}