A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2018-November/155729.html below:

[Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

[Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged) [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)Antoine Pitrou solipsis at pitrou.net
Wed Nov 14 05:20:55 EST 2018
On Wed, 14 Nov 2018 11:03:49 +0100
Victor Stinner <vstinner at redhat.com> wrote:
> 
> Oh, I should stop to promote my "CPython fork" idea.
> 
> There is already an existing VM which is way faster than CPython but
> its performances are limited by the current C API. The VM is called...
> PyPy!
> 
> The bet is that migrating to a new C API would make your C extension faster.

Faster on PyPy... but potentially slower on CPython.  That's what we
(you :-)) need to investigate and solve.  Those macros and inline
functions are actually important for many use cases.

For example in PyArrow we use PySequence_Fast_GET_ITEM() (*) and even
PyType_HasFeature() (**) (to quickly check for multiple base types with
a single fetch and comparison).

(*)
https://github.com/apache/arrow/blob/master/cpp/src/arrow/python/iterators.h#L39-L86
(**)
https://github.com/apache/arrow/blob/master/cpp/src/arrow/python/helpers.cc#L266-L299

Regards

Antoine.


More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4