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.
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
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 :)
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
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/
>
