skip news because this is an implementation detail

CC @encukou @markshannon @scoder @vstinner

I'm wondering whether we should use a special tuple subclass for this. It wouldn't really change much in practice, but it would feel more justified to hack with the tuple size.

I didn't think of the freelist but it's true that I already had bad feelings about messing with the tuple size like that. What do you think of my proposal (see above) of making a special tuple subclass for this?

For a good answer I'd need to write the code :)
Generally, this sounds like an optimization, so consider doing it in two steps:

• Fix the issue simply and robustly (seems to need two allocations and a bunch of refcount poking)
• Afterwards, optimize and measure

For a good answer I'd need to write the code :)

write the code or just see the code (written by me for example)?

Generally, this sounds like an optimization, so consider doing it in two steps:

* Fix the issue simply and robustly (seems to need two allocations and a bunch of refcount poking)

* Afterwards, optimize and measure

This two-step process is going to take more work: it requires to discuss two API designs and implementations instead of one (with the first one going to be thrown away anyway once we do the second).

So, I'd like to do it in one step if possible.

* bunch of refcount poking

On the other hand, adding the "refcount poking" part is pretty simple. So if you agree with doing just that manually (without changing _PyStack_UnpackDict at all), then I'm OK with that.

write the code or just see the code (written by me for example)?

For a relatively complex optimization? benchmark the code, before and after.

This two-step process is going to take more work: it requires to discuss two API designs and implementations instead of one (with the first one going to be thrown away anyway once we do the second).

But without the first, it'd be hard to argue that the tuple subclass actually brings any benefit. Tuple subclasses behave quite differently from exact tuples (they don't use freelists, for one).

On the other hand, adding the "refcount poking" part is pretty simple. So if you agree with doing just that manually (without changing _PyStack_UnpackDict at all), then I'm OK with that.

Definitely! All I ask for before the optimization is a correct baseline.

It might then very well turn out that the optimization is unnecessary.

I decided to drop this idea. It's more controversial than I initially thought and I see why (I can't disagree).

For reference: #14517 optimized _PyStack_UnpackDict in other ways, in particular to create a fast path in the case of no keyword arguments.