Mailman 3 July 2018 - capi-sig

[capi-sig]Fwd: C API and performance
by Antoine Pitrou July 31, 2018

July 31, 2018

Le 31/07/2018 à 18:25, Victor Stinner a écrit : > > 2018-07-31 18:03 GMT+02:00 Antoine Pitrou <solipsis(a)pitrou.net>: >>> For example, PyPy uses different memory allocators depending on the >>> scope and the lifetime of an object. I'm not sure that you can >>> implement such optimization if you are stuck with reference counting. >> >> But what does reference counting have to do with memory allocators >> exactly? > > I … [View More]

1 0

[capi-sig]Re: Adding an official (minimal) Cython-like tool.
by Jeroen Demeyer July 31, 2018

July 31, 2018

On 2018-07-31 17:59, Eric Snow wrote: > Regardless, it would help all parties involved > if there *were* an official tool that was part of CPython (i.e. in the > repo). Why does the tool need to be "official"? I mean, is Sphinx considered to be the "official" tool for Python documentation? I would say that it is de facto standard and that's perfectly fine.

1 0

[capi-sig]Make the stable ABI usable
by Victor Stinner July 31, 2018

July 31, 2018

Hi Gustavo, Le lundi 30 juillet 2018, Stefan Behnel <python_capi(a)behnel.de> a écrit : > Gustavo Carneiro schrieb am 30.07.2018 um 16:18: >> What is the relation to PEP 384? https://www.python.org/dev/peps/pep-0384/ > > The "stable ABI" is a restricted API/ABI that breaks backwards > compatibility with all extension modules out there. If you write code > against this API, then you can make it work in newer CPython versions > without recompilation. This does not … [View More]

6 14

[capi-sig]C API and performance
by Victor Stinner July 31, 2018

July 31, 2018

Antoine Pitrou replied to my "Let's change to C API!" thread on python-dev. I reply here on a new thread on the capi-sig mailing list. 2018-07-31 18:03 GMT+02:00 Antoine Pitrou <solipsis(a)pitrou.net>: >> For example, PyPy uses different memory allocators depending on the >> scope and the lifetime of an object. I'm not sure that you can >> implement such optimization if you are stuck with reference counting. > > But what does reference counting have to do with … [View More]

1 0

[capi-sig]Re: Let's change to C API!
by Jeroen Demeyer July 31, 2018

July 31, 2018

On 2018-07-31 15:36, Victor Stinner wrote: > Don't we already provide source compatibility with the current API? Yes we do. Like I said, Ronald's "level 2" is really the current documented C API which provides source compatibility.

1 0

[capi-sig]Re: Make the stable ABI usable
by Jeroen Demeyer July 31, 2018

July 31, 2018

On 2018-07-31 15:06, Victor Stinner wrote: > But PyArg_ParseTuple(), the question is if we can rely on the fact > that the caller is supposed to hold a strong reference. The caller is supposed to hold a reference. See https://bugs.python.org/issue25750 and https://github.com/python/cpython/pull/6118 for a crash where this is not the case (and somebody please review it!).

1 0

[capi-sig]Re: Let's change to C API!
by Jeroen Demeyer July 31, 2018

July 31, 2018

It seems that your proposal to change the C API really does two independent things: 1. Clean up some of the bad C API, such as PyDict_GetItem() and borrowed references. 2. Hide implementation details and make the ABI more stable. Personally, I agree with 1 but not so much with 2 (Stefan already argued at length why). PS: Please add PyEval_GetFuncName() to the bad C API. It returns the internal const char* inside a borrowed reference to a function __name__. Getting that to work with PEP … [View More]

3 3

[capi-sig]Re: Let's change to C API!
by Jeroen Demeyer July 31, 2018

July 31, 2018

On 2018-07-31 14:02, Ronald Oussoren wrote: > I haven’t had time yet to read through those pages, but I wonder if there shouldn’t be (at least) three levels of API: > > 1) More or less the current full API (with some cleanups), but with full access to internals > 2) Smaller API without access to type internals, but with PyTypeObject and supporting types > 3) The restricted API with a stable ABI (PEP 384) That's exactly the current situation. Your "level 1" is the undocumented … [View More]

2 1

[capi-sig]Second argument of METH_NOARGS functions
by Jeroen Demeyer July 30, 2018

July 30, 2018

I propose to drop the guarantee that the second (unused) argument of a METH_NOARGS function is always NULL. This would allow a minor simplification in PEP 580. For details, see - https://bugs.python.org/issue34280 - https://github.com/python/cpython/pull/8563

1 0