Export the `UNBOUND` / `UNBOUND_ERROR` / `UNBOUND_REMOVE` / `ItemInterpreterDestroyed` in `concurrent.interpreters._queue`

[aisk]

Bug report

Bug description:

We have exported the create function from concurrent.interpreters._queue to concurrent.interpreters:

https://github.com/python/cpython/blob/8288f3693f50058ad9b9fe04e01f5dad902d8bad/Lib/concurrent/interpreters/__init__.py#L13C15-L13C27

But the create function accept an optional parameter unbounditems, which can be one of UNBOUND / UNBOUND_ERROR / UNBOUND_REMOVE:

cpython/Lib/concurrent/interpreters/_queues.py

Line 65 in 8288f36

def create(maxsize=0, *, unbounditems=UNBOUND):

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

Linked PRs

• gh-139360: Export some names in concurrent.interpreters #139362

[aisk]

@ericsnowcurrently

[ericsnowcurrently]

It might be okay to do this I'm not sure yet. My immediate reaction is that people should just use interpreters.queues and that interpreters.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 drop create_queue() though.

Would it be enough to point people to the interpreters.queues in the create_queue() docs?

[aisk]

Hi @ericsnowcurrently,

My immediate reaction is that people should just use interpreters.queues and that interpreters.create_queue() is just a convenience

You mean using concurrent.interpreters._queues here? 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]

Ah, this all makes more sense now. Honestly, I forgot that I changed interpreters.queues to interpreters._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]

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 _queues as a temporary solution.

So I think we can close this now and update #139358 to not document the unbounditems parameter.

What do you think?

[ericsnowcurrently]

Sounds good.

[aisk]

Thanks, closing this.

Can you please help me review #139358 if you have time? It only contains necessary changes and fixes for the interpreters module documentation.