egaudry added the comment:
I originally submitted an issue asking for having the symbol exported.
But, as Victor mentioned, this part of the code was changed between 2.7 and 3.x.
I then asked if the part of the code defining the symbol (and not used anymore)
in 3.7 could be removed/cleaned
egaudry added the comment:
Yes, the only thing that remains to be done is cleaning objimpl.h.
--
title: [2.7] Expose _PyGC_generation0 for allowing internal use directly from a
CPython extension -> [3.7] clean extern PyGC_Head *_PyGC_generation0; in
Include/objimpl.h
versi
egaudry added the comment:
Victor,
extern PyGC_Head *_PyGC_generation0;
is located at line 374 of Include/objimpl.h (ifndef Py_LIMITED_API).
I used it from a CPython extension we are developing as an handle to the
collection of objects being garbage collected.
>From what you explained
egaudry added the comment:
closing as this no real point in making something available in an EOL branch.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
New submission from egaudry :
When looking at the pydebug.h header file, I see that some symbols are not
declared as exported.
For instance, I would like to be able to change the value of the
Py_TabcheckFlag when running specific codelines.
Any chance this patch could be added
New submission from egaudry :
Hi
I would like to be able to get an handle on PyGC_Head*_PyGC_generation0 from a
CPython extension.
This is possible when building Python on a Posix host, but not on Windows
because of a missing PyAPI_DATA wrapping of the said object in the objimpl.h
header
egaudry added the comment:
Hi, I think that there are some issues in the last patch
(0001-Build-or-disable-readline-module-with-Editline.patch) made available.
For instance, the using_libedit_emulation variable should be protected by
DETECT_EDITLINE ifdef (and not SUPPORT_EDITLINE). And the
egaudry added the comment:
Hi Thomas,
I think we should open a new issue (child from issue 4120), just to make
sure the whole thing remains understandable.
Regards,
Eloi
Thomas Heller wrote:
> Thomas Heller added the comment:
>
> I'm not sure this issue is really done. The
egaudry added the comment:
I came across this (very) interesting thread after experiencing some
redistribution issue with a python(2.6)-based package built with msvc9
compiler.
I used to struggled with the SxS Microsoft policy in the past. After I
finally went for the private assembly/crt