Just be sure I understood, the problem is that the arg spec for _queues.put() has one too many items in it. Is that right?

I'm pretty sure the $p shouldn't be there. The "fallback" arg is an int flag ¹, so it should have an "i" in the spec. Thus, the spec for queuesmod_create() should not change and for queuesmod_put() it should be "O&O|ii:put".

FWIW, at the time, with the feature freeze at hand, I didn't worry about ironing out little API quirks (e.g. placeholder args) in the low-level module. It isn't exposed to users, right?

To be clear, I left room for other "fallback" options later, rather than it being a definite binary choice. Sorry that wasn't more clear. Then again, that decision was probably a premature accommodation for a possible future. I figure it doesn't matter much though.

Just be sure I understood, the problem is that the arg spec for _queues.put() has one too many items in it. Is that right?

Yes, specifically that the format spec for PyArg_ParseTupleAndKeywords expected five args, but kwlist gave only four.

I'm pretty sure the $p shouldn't be there. The "fallback" arg is an int flag 1, so it should have an "i" in the spec. Thus, the spec for queuesmod_create() should not change and for queuesmod_put() it should be "O&O|ii:put".

I've updated the PR. I don't think we need the test anymore given this is the current behaviour -- we are just removing the errant $p. Please would you be able to review/approve the updated PR?

FWIW, at the time, with the feature freeze at hand, I didn't worry about ironing out little API quirks (e.g. placeholder args) in the low-level module. It isn't exposed to users, right?

Definitely the correct choice. _interpqueues is technically exposed to users by dint of being importable, but is entirely undocumented and of course a private module. This PR is just a correctness fix that Serhiy spotted, but it would nevertheless be good to include it in 3.14.0 candidate 3 / final.

A