I've pushed a new version of the patch that I intend to merge tomorrow.

The last version has only one minor change: it uses fast-path for "slightly" non-compact dicts too (dicts don't use *at most* 3 entries).  This protects us from pathological cases when a huge dict being almost emptied with pop/del and then gets copied -- we indeed want the copy to be compact.

Although I believe that the real issue is that del and pop don't compact dicts from time to time, but I don't want that issue to hold off this patch in any way.

> If you will make dict copying removing holes and extend your patch to dict constructor, it could be more useful.

It's already useful -- I'm supporting a large code base (>0.5M LOC) which uses dict.copy() extensively, and it shows up in profile.  I've seen it in many other places (particularly ORMs love to store information in dicts and use dict.copy() to track dirty state/changes).  Please don't say that dict.copy() is not a common operation or that dict(other_dict) is more common than other_dict.copy() -- that's simply incorrect.

> The side effect of this patch is making dict.copy() atomic. This is a worthy feature if extent it to dict constructor.

I agree.  I'll work on that later in a follow-up PR.  Let's move in small steps.