What you mean is something like

if(PyDIct_CheckExact(o)) {
    PyDIct_GetItemWIthError(o, key)
}
else {
// The current code goes here
}

right? (Whenever I see the word "specialize" now I immediately think of PEP 659, so I wanted to clear that up).

Link to the current match_keys function just to make it easier to discuss:

I was thinking of having a second copy of the function that operates on dicts. So match_keys starts something like:

if (PyDict_CheckExact(map)) {
    return match_keys_dict(tstate, map, keys);
}

and match_keys_dict then uses PyDIct_GetItemWIthError(o, key) instead of calling mapping.get.

And no - I wasn't proposing anything like PEP 659 - just an if statement to pick a slightly faster implementation

In theory this seems sound to me and I'm +1. But I'll wait to hear what @brandtbucher has to say.

I actually discovered during a PyCon all-nighter (thanks to some nerd-sniping by @tonybaloney) that we can get a huge speedup for mapping patterns by moving this logic into the bytecode and:

• removing the length check
• using CONTAINS_OP and BINARY_SUBSCR instead of two-argument get
• not building a set to check for duplicate keys if they’re all known statically (common case)
• some other tidying up

As a bonus, with this scheme we get dictionary specialization for free, since the logic is being moved “into Python code”.

My plan is to make this change in 3.12. I have a branch with the work, just haven’t gotten around to cleaning it up and opening a PR yet. 😬

I’d be okay merging a PR that does what you describe now since it’s always better to make things faster. But just know that there’s a pretty good chance it could get completely ripped out and replaced before 3.12 is released, haha.

Unfortunately it’s documented that get has to be used, to prevent defaultdict’s behaviour from being triggered.

Indeed, that’s the main sticking point. Although I'm pretty confident that it won't be much of an issue because:

• We already require the Mapping interface, which includes containment and subscription
• Checking for containment before subscription still avoids creating new keys in defaultdicts, which is the main reason why we went with 2-argument get in the first place