capi-sig April 2020

capi-sig@python.org

10 participants
7 discussions

Should getter function return a strong reference?

by Victor Stinner

Hi, I added PyThreadState_GetFrame() and PyFrame_GetCode() functions to Python 3.9 (as part of my work to make structures opaque). These functions are basically getter to access PyThreadState.frame and PyFrameObject.f_code members. Example: struct _frame* PyThreadState_GetFrame(PyThreadState *tstate) { assert(tstate != NULL); return tstate->frame; } These functions currently return *borrowed* references. I understood that borrowed references makes it harder to write an efficient implementation of Python: https://github.com/vstinner/misc/blob/master/cpython/pep-opaque-c-api.rst#b… For example, PyPy has to convert all items of a list to PyObject when a C extension module calls PyList_GetItem(). Question: should I modify PyThreadState_GetFrame() and PyFrame_GetCode() functions to return a *strong* reference instead? Victor -- Night gathers, and now my watch begins. It shall not end until my death.

6 months

Re: [Python-Dev] Problem with instantiating a C extension class from another class

by Musbur

On Sat, 11 Apr 2020 01:07:24 +0000 (UTC) Daniel Scott <scottdaniel760(a)yahoo.com> wrote: > Are you calling PyType_Ready on your types? > > It is difficult to debug this without a full example. If you have a > repo with the code on github or gitlab or bitbucket, feel free to > ping me @mattip to take a look. Hello Daniel, here's a fully self-contained example. Thanks for taking a look! https://github.com/musbur/testmodule

6 months, 3 weeks

PEP: Modify the C API to hide implementation details

by Victor Stinner

Hi, I started a discussion on python-dev about my new PEP "Modify the C API to hide implementation details": https://mail.python.org/archives/list/python-dev@python.org/thread/HKM774XK… The PEP: https://github.com/vstinner/misc/blob/master/cpython/pep-opaque-c-api.rst#d… I advice you to participate on python-dev. If you prefer to not subscribe to python-dev, you may reply here. Victor -- Night gathers, and now my watch begins. It shall not end until my death.

6 months, 3 weeks

missing `UCHAR` in `ctypes.wintypes`.

by Kingsley McDonald

hello :) (terribly sorry, i might have accidentally sent an unfinished email before this!) i'm creating a small module for interacting with SCSI devices, and i'm making use of `ctypes` to interact with the win32 API for my windows implementation. in doing so, i've had to define my own version of the SCSI_PASS_THROUGH_DIRECT<https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddscsi/ns-n…> struct using `ctypes.Structure`. when reading around earlier today, i found the `ctypes.wintypes` module and was happy to see that it could help me write my code to be more consistent with the definitions found in the win32 API. however, the `UCHAR` type appears many times in that struct i mentioned, and yet is not defined in the `ctypes.wintypes` module (in fact, it is commented out in the source with no reason given). i understand that there is probably a reason that i'm unaware of for not having a definition of `c_uchar` in the `ctypes` module. however, i don't understand why an equivalent type (such as `ctypes.c_ubyte`) hasn't been used to define `UCHAR` in the `ctypes.wintypes` module to maintain consistency with the windows API. i know that it is a bit silly to make such a big deal over an alias, but the point of these aliases is to make code look more consistent, and that's hardly the case when there's an exception to the rule! :D if this missing definition was intentional, then what is the reason behind that? or if it has been simply overlooked, then can the definition be created for the sake of consistency? i would love to make the relevant amendment myself if that is the case ^^ thanks! (and sorry again if the other email sent!) kingsley mcdonald :)

6 months, 3 weeks

Macros defined in CPython headers -> move to function-like macros

by Sylvain Corlay

Hi All, I hope I am not breaking any rules by posting here. I maintain a number of libraries and C++ Python extensions and one slightly annoying thing about the Python.h headers is that it includes headers defining macros such as *snprintf*. In C++, this collides with std::snprintf defined in the <cstdio>. One backward-compatible way to make these collision less likely would be to make this macro a function-style macro - so that we could prevent the macro expansion in client code by simply adding parentheses to the calls to the actual functions. (std::snprintf)(foobar) In my opinion, it would make the world a better place for C++ Python extension authors :) Best, Sylvain

6 months, 3 weeks

missing `UCHAR` in `ctypes.wintypes`?

by Kingsley McDonald

hello :) i'm writing a small library

6 months, 3 weeks

Re: [Python-Dev] Problem with instantiating a C extension class from another class

by Nick Coghlan

Hi Musbur, While python-dev is specifically for core development, the "specific interest group" mailing lists are for both change proposals and existing usage questions. I've cc'ed capi-sig on this reply. Cheers, Nick. On Sat., 4 Apr. 2020, 2:02 am Musbur, <musbur(a)posteo.org> wrote: > Hello, > > (I've asked this question before on python-list but only got scarce > and ultimately unhelpful answers. Although this isn't about Python > development itself, I'm assuming that there is more CPython > knowledge on this list than on the other, so please bear with me.) > > I've written a C extension module, each defining a class > (called Series and CLHist, respectively). I can import both modules in > Python and use the classes. Everything works fine, also according to > valgrind. > > Now I want to return a Series instance directly from a CLHist > method, and that immediately crashes Python with a segfault. > > Here's a bit of code and just the _new, _init, and _finalize methods > which I've sprinkled with debugging code. When I instantiate a Series > object from Python, I see output from all three methods. When I call > pyseries_new() from C, none of the three functions are called and it > crashes. > > At some point I thought maybe I should call PyType_Ready() from the C > side before instantiating Series. In a "standard" (system) Python > installation, it printed the desired debugging output and crashed > later. Under a debugging Python installation I built it outputs > nothing except an interesting post-mortem "Fatal Python error: UNREF > invalid object" (see below). > > Here's my C code with the boilerplate stuff left out. > > typedef struct { > PyObject_HEAD > struct clh_series *series; > } Series; > > static PyObject *Series_new(PyTypeObject *type, > PyObject *args, PyObject *kw) { > Series *self; > > self = (Series *) type->tp_alloc(type, 0); > fprintf(stderr, "Series_new(%p)\n", self); > self->series = NULL; > return (PyObject*)self; > } > > static int Series_init(Series *self, PyObject *args, PyObject *kw) { > fprintf(stderr, "Series_init(%p)\n", self); > self->series = NULL; > return 0; > } > > static void Series_finalize(PyObject *self) { > fprintf(stderr, "Series_finalize(%p)\n", self); > clh_series_free(((Series*)self)->series); > } > > /* To create a new Series object directly from C */ > PyObject *pyseries_new(struct clh_series *series) { > Series *pyseries; > > pyseries = PyObject_New(Series, &series_type); > PyObject_Init((PyObject *)pyseries, &series_type); > pyseries->series = series; > return (PyObject *) pyseries; > } > > Here's the debugging output: > > * ob > object : <refcnt 0 at 0x7f1a4e2f97a8> > type : tuple > refcount: 0 > address : 0x7f1a4e2f97a8 > * op->_ob_prev->_ob_next > object : <_Series object at 0x7f1a4e2ee9d0> > type : _Series > refcount: 1 > address : 0x7f1a4e2ee9d0 > * op->_ob_next->_ob_prev > object : <refcnt 0 at 0x7f1a4e2f97a8> > type : tuple > refcount: 0 > address : 0x7f1a4e2f97a8 > Fatal Python error: UNREF invalid object > _______________________________________________ > Python-Dev mailing list -- python-dev(a)python.org > To unsubscribe send an email to python-dev-leave(a)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/ILMRMQ6… > Code of Conduct: http://python.org/psf/codeofconduct/ >

6 months, 4 weeks

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

capi-sig April 2020