Mailman 3 September 2018 - capi-sig

[capi-sig]Re: No C API if it's not doable in Python
by Jeroen Demeyer Sept. 7, 2018

Sept. 7, 2018

On 2018-09-07 15:17, Victor Stinner wrote: > I'm not sure if we can hide some functions for > regular C extensions, but only give access to Cython? Which problem would that solve? If you're happy with Cython using "internal" functions, why shouldn't other C extensions use those same internal functions?

1 0

[capi-sig]No C API if it's not doable in Python
by Victor Stinner Sept. 7, 2018

Sept. 7, 2018

Le ven. 7 sept. 2018 à 12:45, M.-A. Lemburg <mal(a)egenix.com> a écrit : > > On 07.09.2018 11:46, Victor Stinner wrote: > > I'm trying to remove functions from the C API which allow to do things > > which are not possible at the Python level: > > https://pythoncapi.readthedocs.io/bad_api.html#no-public-c-functions-if-it-… > > > > It's a request coming from PyPy developers. > > There are always things which you have to be able to do at the > C … [View More]

3 3

[capi-sig]Re: Open questions about borrowed references
by Jeroen Demeyer Sept. 5, 2018

Sept. 5, 2018

On 2018-09-05 15:19, Hugh Fisher wrote: > And this happens to be exactly what Apple did when they added tagged > pointers to Objective-C. They told programmers not to access objectptr->isa > directly, instead to use OBJECT_GETCLASS(objectptr). Then later they > started implementing some objects as tagged pointers, and only code > that hadn't been updated broke. OBJECT_GETCLASS was the "stable > ABI" This is a stable API, but I would guess not a stable ABI. Victor Stinner … [View More]

2 1

[capi-sig]Experiment Python without Py_TYPE()
by Victor Stinner Sept. 5, 2018

Sept. 5, 2018

Hi, In my previous "Open questions about borrowed references" thread, I asked if it's an issue or not that Py_TYPE() returns a borrowed reference. It seems like most people say that it's not an issue. If you want to discuss if Py_TYPE() is an issue, please contribute to the other thread. Here I only want to share my results. Honestly, I'm still not 100% convinced that Py_TYPE() is an issue :-) I experimented anyway a C API without Py_TYPE(). I chose to add 3 functions/features: * ``… [View More]

1 0

[capi-sig]Re: Open questions about borrowed references
by Jeroen Demeyer Sept. 5, 2018

Sept. 5, 2018

On 2018-09-05 13:49, Petr Viktorin wrote: > I'm not at a computer right now, but AFAIK if <class int>'s refcount > drops to zero, we still try to deallocate it, and that causes an > assertion and terminates the interpreter. You're right but that's besides the original point. If code uses refcounting correctly (regardless of using an "old" or "new" API), then the class int will never be deallocated.

4 3

[capi-sig]Re: Open questions about borrowed references
by Jeroen Demeyer Sept. 5, 2018

Sept. 5, 2018

On 2018-09-05 15:20, Victor Stinner wrote: > PyObject *obj = create_object(); > PyTypeObject *type = Py_TYPE(obj); > Py_DECREF(obj); > /* ... */ > /* type is now a dangling pointer */ > > Do you consider that this example uses reference counting "correctly"? No because Py_TYPE() is known to return a borrowed reference. So, if you want to do anything with it besides immediately using it, you need to Py_INCREF() it.

1 0

[capi-sig]Re: static allocation of extension types
by Jeroen Demeyer Sept. 5, 2018

Sept. 5, 2018

On 2018-09-05 14:51, Hugh Fisher wrote: > As of Python 3.6 a static type cannot be a subclass of a dynamic > type This is true, but I don't really know why. This was added by Serhiy Storchaka in https://bugs.python.org/issue22079 but without much rationale. I'm guessing that heap types are too dynamic to reliably subclass from, but I don't really know... If you really have good reasons for having an extension type subclassing a heap type, I would love to know them. Jeroen.

2 1

[capi-sig]Re: Open questions about borrowed references
by Jeroen Demeyer Sept. 5, 2018

Sept. 5, 2018

On 2018-09-05 13:32, Petr Viktorin wrote: > Only the type object, <class int>, would be immortal. This is already the case. Extension types are statically allocated, so they are effectively immortal.

3 2

[capi-sig]Re: Open questions about borrowed references
by Jeroen Demeyer Sept. 4, 2018

Sept. 4, 2018

On 2018-09-05 00:12, Victor Stinner wrote: > Examples of Py_TYPE() usage. My issue is that replacing Py_TYPE() with > a new function which increment the reference counter of the type would > make the code less straightforward. You misunderstood my question. Why would you want to replace Py_TYPE() with a new function which increments the reference counter of the type? It seems to me that you are proposing a solution in search of a problem...

1 0

[capi-sig]Re: Open questions about borrowed references
by Jeroen Demeyer Sept. 4, 2018

Sept. 4, 2018

On 2018-09-04 23:28, Victor Stinner wrote: > Hi, > > Ah! I succeeded to get a dangling pointer to a deallocated type object > using Py_TYPE(). The example is designed to trigger the bug, but it > proves that it's important to hold a strong reference to the type when > using Py_TYPE(). Maybe it's not an issue for the normal case in the > wild, but at least my example provides that there is an issue in a > corner case which waits to bite you. What's your point really? It'… [View More]

3 3