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 ? _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HHXVWQ4GJSBQFYBVW6IH42DE75BHUXVR/ Code of Conduct: http://python.org/psf/codeofconduct/
