@vsajip I suspect this is caused by the fact that you instantiate a queue to get its runtime type. Maybe a protocol approach for a queue would be better? I don't know if the queue you expect should be any queue or if whatever is a queue-like API is fine.

A queue-like API is all that's needed, but by protocol approach you mean just checking for the existence of queue methods used by logging? The fundamental problem here is that a proxy is used from which you can't easily infer what type the proxy is to. Another, perhaps more generally useful way might be to expose the underlying runtime type on the proxy so that it can be readily queried.

A queue-like API is all that's needed, but by protocol approach you mean just checking for the existence of queue methods used by logging

Yes. Don't really care about the type itself, just checking that methods of certain names exist, not even their signatures. And if something goes wrong, there would be a TypeError when you want to use the queue I think. You could reduce issues by having a well-documented section on what kind of queue API you expect, and that should be enough I think.

Another, perhaps more generally useful way might be to expose the underlying runtime type on the proxy so that it can be readily queried

IIRC, the proxy is a local class and it does not necessarily require to have a class. It's a bit hard to explain here but if you look at multiprocessing.managers.BaseManager.register and how queue classes are registered in managers, you'll see that keeping track of the base type might be more tricky.

Right, I had a quick look when this issue came up before and it didn't seem that straightforward, which is why I went with the approach of instantiating the queue to get its type 😞

So... protocol approach it will be? (I can make a PR tomorrow or in two days)