[issue38542] [3.7] clean extern PyGC_Head *_PyGC_generation0; in Include/objimpl.h
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. This is why it was tagged back to 3.7. As it was already removed in newer version (3.8?) and because the policy is not to clean dead-code, this issue is now closed. -- ___ Python tracker <https://bugs.python.org/issue38542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38542] [3.7] clean extern PyGC_Head *_PyGC_generation0; in Include/objimpl.h
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 versions: +Python 3.7 -Python 2.7 ___ Python tracker <https://bugs.python.org/issue38542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38542] [2.7] Expose _PyGC_generation0 for allowing internal use directly from a CPython extension
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, I should use the _PyRuntime exported symbol to get >the handle this PyGC_Head. I'll do this. I guess that cleaning the Include/objimpl.h is the only remaining action to do then. Thanks for your feedback. -- ___ Python tracker <https://bugs.python.org/issue38542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38543] [2.7] Expose Py_TabcheckFlag as other PyAPI_DATA flag
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/issue38543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38543] Expose Py_TabcheckFlag as other PyAPI_DATA flag
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 ? -- components: Interpreter Core files: tab.diff keywords: patch messages: 355035 nosy: egaudry priority: normal severity: normal status: open title: Expose Py_TabcheckFlag as other PyAPI_DATA flag type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file48672/tab.diff ___ Python tracker <https://bugs.python.org/issue38543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38542] Expose _PyGC_generation0 for allowing internal use directly from a CPython extension
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. Having the possibility to inspect the PyGC_Head here can be very useful when customizing the way a garbage-collectable object created from CPython extension would be cleaned/inspected, etc. Any chance this patch could be added to get the same capabilities on Windows and Posix platforms ? Thanks for your feedback, Eloi -- components: Interpreter Core files: gc.diff keywords: patch messages: 355034 nosy: egaudry priority: normal severity: normal status: open title: Expose _PyGC_generation0 for allowing internal use directly from a CPython extension type: enhancement versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file48671/gc.diff ___ Python tracker <https://bugs.python.org/issue38542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
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 setup.py file mentioned a 'readline_lib' string instead of the readline_lib variable. I am interested by being able to build python without readline but libedit instead too. -- nosy: +egaudry ___ Python tracker <https://bugs.python.org/issue13501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
egaudry e...@fft.be 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 thel...@ctypes.org added the comment: I'm not sure this issue is really done. The current state works fine, but there is one problem remaining: There are Python extensions that seem to need a manifest pointing to the MSVC runtime libs: dlls that start in-process com servers, like pythoncom.dll (from the PyWin32 extension), and also _ctypes.pyd plays this role. First question: Open a new issue, or discuss it in this one (and repoen it)? -- nosy: +theller ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4120 ___ -- Eloi Gaudry Free Field Technologies Axis Park Louvain-la-Neuve Rue Emile Francqui, 1 B-1435 Mont-Saint Guibert BELGIUM Company Phone: +32 10 487 959 Company Fax: +32 10 454 626 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC
egaudry e...@fft.be 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 runtime redistribution solution, I always succeeded to deliver a stand-alone package to any windows host around (I got full control on what's actually build and distribute). Having now (using the disutils module) the manifest file embedded in the python extension actually forbids this redistribution solution, for the reasons that have been posted here (SxS policy), unless a private assembly/crt runtime is provided next to each built extension. IMHO, this is not a convenient (and common) way to redistribute a software. This is why I fully agree with the propositions that were made here, i.e. not embedding manifest into a python extension built with the distutils module and msvc. Could anyone tell us if a decision has been made about such a change ? Thanks, Eloi -- nosy: +egaudry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
