RetroSearch Browse

Wed Nov 21 06:08:06 EST 2018 · https://mail.python.org/pipermail/python-dev/2018-November/155797.html

On Tue, 20 Nov 2018 23:17:05 +0100
Victor Stinner <vstinner at redhat.com> wrote:
> Le mar. 20 nov. 2018 à 23:08, Stefan Krah <stefan at bytereef.org> a écrit :
> > Intuitively, it should probably not be part of a limited API, but I never
> > quite understood the purpose of this API, because I regularly need any
> > function that I can get my hands on.
> > (...)
> > Reading typed strings directly into an array with minimal overhead.  
> 
> IMHO performance and hiding implementation details are exclusive. You
> should either use the C API with impl. details for best performances,
> or use a "limited" C API for best compatibility.
> 
> Since I would like to not touch the C API with impl. details, you can
> imagine to have two compilation modes: one for best performances on
> CPython, one for best compatibility (ex: compatible with PyPy). I'm
> not sure how the "compilation mode" will be selected.

You mean the same API can compile to two different things depending on
a configuration?

I expect it to be error-prone.  For example, let's suppose I want to
compile in a given mode, but I also use Numpy's C API.  Will the
compile mode "leak" to Numpy as well?  What if a third-party header
includes "Python.h" before I do the "#define" that's necessary?

Regards

Antoine.

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

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

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