GeezerVison

If there is an error with the creation, you could maybe wrap that one in an try-except block? (probably catching an OSError but I'm not sure).

Would we want to behave different in this case? I'm not sure what the expected behaviour would be here. The only thing I could think of that would make sense is to raise the usual TypeError from the error the instantiation raised, but that would still result in roughly the same traceback as when calling .configure, since it already re-raises exceptions.

Or are you suggesting we take a different path here when we encounter an error?

No, I didn't know about the exceptino being wrapped by configure so it may be fine. The thing is, I don't know whether we could be more precise in the error being raised so that you know that's is because multiprocessing queues are not supported.

For instance:

• you use a bad BaseProxy object which is not a queue and MM().Queue() is fine -> you want the TypeError
• let's say you have a queue-like object for your readonly system that inherits from MM().Queue() with some tweaks. In this case, you will be able to create your special queue object and expect it to work but MM().Queue() would fail. So instead of having some generic error due to that instantiation, the message could be something else. But I'm not sure whether this corner case is too convoluted or not.

I think, I'll just leave the decision to Vinay because they're the maintainer and creator of the logging module.

But I'm not sure whether this corner case is too convoluted or not.

Yeah, I was worrying about that. I didn't want to put too much stuff in here just to handle this case. IMO the proper proper fix for this would be to add some level of introspection capabilities in BaseProxy, that allows to perform such checks without creating an instance of the type you want to check against first.

Maybe it would make sense to add something in the docs for this, as there's quite a few special cases now that might not be immediately intuitive

"Flat is better than nested", so I agree that it's reasonable to rearrange the various tests on qspec in this way.