On Wed, Jul 1, 2020 at 4:09 AM Antoine Pitrou <solip...@pitrou.net> wrote:
> How does this help third-party extensions? > If the cost is high enough, exposing the guts of a function to allow the compiler to inline it is not unreasonable; all of the major compilers have ways to inline things that are technically across a dynamic boundary, if you declare them properly. The trade-off is accepting that it may have to be rebuilt at some point, but an ABI change is less painful than an API change. Relying on this kind of "optimized interface" would have to be opt-in, since most won't need it and it would be actively harmful for portability. Actually, that's probably an attractive nuisance, better to just make extension writers copy-paste the function into their own codebase if they need performance that badly for a specific call. Better to identify an actual existing case that's degraded by the change and can be tested against than a hypothetical, though. The macos build is already getting fixed thanks to that!
_______________________________________________ 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/DZBO5HFAYZ57L26GHFKRYCUYOFBOEJT7/ Code of Conduct: http://python.org/psf/codeofconduct/
