Repository navigation
Export the UNBOUND / UNBOUND_ERROR / UNBOUND_REMOVE / ItemInterpreterDestroyed in concurrent.interpreters._queue #139360
Closed as not planned
Description
Bug report
Bug description:
We have exported the create function from concurrent.interpreters._queue to concurrent.interpreters:
But the create function accept an optional parameter unbounditems, which can be one of UNBOUND / UNBOUND_ERROR / UNBOUND_REMOVE:
Besides of this, put / put_nowait methods may raise ItemInterpreterDestroyed if we specify the unbounditems to UNBOUND_ERROR.
As a result, we should export them to concurrent.interpreters from concurrent.interpreters._queue.
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Activity
aisk commentedon Sep 26, 2025
@ericsnowcurrently
ericsnowcurrently commentedon Sep 26, 2025
It might be okay to do this I'm not sure yet. My immediate reaction is that people should just use
interpreters.queuesand thatinterpreters.create_queue()is just a convenience However, maybe my instinct is off.I suppose then that I wouldn't have added
create_queue(). I wanted (and want) to minimize clutter and keep the modules focused. It's probably too late to dropcreate_queue()though.Would it be enough to point people to the
interpreters.queuesin thecreate_queue()docs?aisk commentedon Sep 26, 2025
Hi @ericsnowcurrently,
You mean using
concurrent.interpreters._queueshere? Since it has an underscore prefix in the module's name, it is likely a private module, and users are discouraged from using it?ericsnowcurrently commentedon Sep 26, 2025
Ah, this all makes more sense now. Honestly, I forgot that I changed
interpreters.queuestointerpreters._queues.FWIW, I made that change from public to private to simplify the proposed API a little and make it easier for the steering council to accept the PEP. My intention was to expose it eventually.
I'd definitely rather do that than expose it all through the top-level module. That makes it a little trickier for 3.14.0, but maybe @hugovk would be okay with slipping that in? Otherwise, I guess we'd just tell people to get the extra stuff from the private module (in 3.14 at least).
aisk commentedon Sep 27, 2025
Hi @ericsnowcurrently, I found this when I was proposing #139358, so if we want to make queues public in the future, I think it's OK to not document these parameters, and if users want to use them, they can use the private
_queuesas a temporary solution.So I think we can close this now and update #139358 to not document the
unbounditemsparameter.What do you think?
ericsnowcurrently commentedon Sep 29, 2025
Sounds good.
aisk commentedon Sep 29, 2025
Thanks, closing this.
Can you please help me review #139358 if you have time? It only contains necessary changes and fixes for the
interpretersmodule documentation.