Stephen J. Turnbull wrote:
You take a hunk of the standard library (in this case it would have to be an accelerator written in C since you want to compare C++ vs. C) or interpreter code, and translate it to the new syntax. Now, *INCREF and friends are frequently cited as annoyances or even warts, so your suggestion of std::shared _ptr<> seemed plausible to me. But Antoine peeked at it and points out it's not that easy, for performance reasons you can't use it "as is". It's true that you could reimplement it, but then it's not std::shared_ptr<> any more and the only benefit left is that it looks familiar to C++ programmers (and may mislead *them* into thinking about it as if it were exactly std::shared_ptr<>).
Re-implementing of std::shared _ptr<> for single thread is smallest of the problems
And that's why you need to do more work than arguing that in principle C++ is just a better language than C. We've been hearing that for 4 decades now (at least we greybeards have), and we've discovered that for many existing applications, C++ may be better but the cost of converting large swaths of C code to equivalent C++ that passes all tests is too big. Python may very well be one of them. So if you're not going to do the work to demonstrate big wins from using C++ instead of C in actual Python implementation code, I think you're wasting your posts.
I thought about it, but will CPython accept the PR for this changes if it would show benefits ?