[issue40642] Cpython "pystate.h" subdirectory wrong

Xi Ruoyao added the comment: Dup of #39026. And the proposed fix is nack'ed in #39026. -- ___ Python tracker ___ ___

[issue43872] Unable to compile cpython in Visual Studio 2019

Eric V. Smith added the comment: Okay, and good luck! -- resolution: -> not a bug ___ Python tracker ___ ___ Python-bugs-list

[issue43872] Unable to compile cpython in Visual Studio 2019

Shreyan Avigyan added the comment: I'm not able to reproduce the error right now. I think I forgot to clean all object files and other stuff created during compilation and therefore was witnessing the error during rebuilding. I'm closing this issue for now. If I come across this error in

[issue43872] Unable to compile cpython in Visual Studio 2019

Change by Shreyan Avigyan : -- stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue43872] Unable to compile cpython in Visual Studio 2019

Eric V. Smith added the comment: It's almost certainly not a bug in CPython. But you haven't even shown us what the error is, so it's impossible to say. What error are you seeing? -- nosy: +eric.smith ___ Python tracker <https://bugs.python.

[issue43872] Unable to compile cpython in Visual Studio 2019

New submission from Shreyan Avigyan : Recently, I'm having some problem compiling cpython from Visual Studio 2019. I'm able to compile using the build.bat script. I'm using Visual Studio 2019 for about 2-3 months now for compiling and developing cpython. But unfortunately, some error occurs

[issue43416] Add README files in Include/cpython and Include/internal

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue43416] Add README files in Include/cpython and Include/internal

STINNER Victor added the comment: New changeset 929c9039fe0468cb37e0811ddfb7b67c98353ea8 by Erlend Egeberg Aasland in branch 'master': bpo-43416: Add Include/README.rst (GH-24884) https://github.com/python/cpython/commit/929c9039fe0468cb37e0811ddfb7b67c98353ea8

[issue39091] _PyErr_CreateException() must check that the result is an exception (CPython Segfault in 5 lines of code)

Change by Irit Katriel : -- versions: +Python 3.10 -Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

STINNER Victor added the comment: New changeset 56f031ec5281723b7c617edfa5748f2ae6a4c347 by Hai Shi in branch 'master': bpo-35134: Add include/cpython/compile.h (GH-24922) https://github.com/python/cpython/commit/56f031ec5281723b7c617edfa5748f2ae6a4c347

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Change by hai shi : -- nosy: +shihai1991 nosy_count: 8.0 -> 9.0 pull_requests: +23686 pull_request: https://github.com/python/cpython/pull/24922 ___ Python tracker <https://bugs.python.org/issu

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Change by Erlend Egeberg Aasland : -- nosy: +erlendaasland nosy_count: 7.0 -> 8.0 pull_requests: +23644 pull_request: https://github.com/python/cpython/pull/24884 ___ Python tracker <https://bugs.python.org/issu

[issue43416] Add README files in Include/cpython and Include/internal

Change by Erlend Egeberg Aasland : -- keywords: +patch nosy: +erlendaasland nosy_count: 3.0 -> 4.0 pull_requests: +23643 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24884 ___ Python tracker <https://bugs.p

[issue42322] Spectre mitigations in CPython interpreter

Gregory P. Smith added the comment: Compiling everything (your entire OS and libraries and CPython itself) with compiler mitigations is recommended. I agree, there is nothing specific we need to do within CPython itself. -- nosy: +gregory.p.smith resolution: -> not a bug st

[issue43416] Add README files in Include/cpython and Include/internal

STINNER Victor added the comment: * Include/internal/ with extern: C API which must not and can not be used outside CPython code base, only stdlib extensions built as built-in extensions can use it. * Include/internal/ with PyAPI_FUNC/PyAPI_DATA: API which should be be used outside CPython

[issue43416] Add README files in Include/cpython and Include/internal

difference between Include/cpython and Include/internal. -- assignee: docs@python components: Documentation, Interpreter Core messages: 388196 nosy: docs@python, serhiy.storchaka, vstinner priority: normal severity: normal status: open title: Add README files in Include/cpython and Include/int

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Change by Nicholas Sim : -- pull_requests: +23538 pull_request: https://github.com/python/cpython/pull/24770 ___ Python tracker <https://bugs.python.org/issue35

[issue40642] Cpython "pystate.h" subdirectory wrong

Change by Xi Ruoyao : -- keywords: +patch nosy: +xry111 nosy_count: 3.0 -> 4.0 pull_requests: +23514 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24744 ___ Python tracker <https://bugs.python.org/i

[issue43377] _PyErr_Display should be available in the CPython-specific API

Change by Max Bélanger : -- keywords: +patch nosy: +maxbelanger nosy_count: 1.0 -> 2.0 pull_requests: +23495 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24719 ___ Python tracker <https://bugs.python.org/i

[issue43377] _PyErr_Display should be available in the CPython-specific API

restructuring in Python 3.8+, that function is a bit harder to call. It's exported, but is considered "internal" and thus requires defining `Py_BUILD_CORE`. I was wondering: why not expose it under "Include/cpython"? It seems like a generic-enough helper, similar to `_PyEr

[issue40642] Cpython "pystate.h" subdirectory wrong

Andrew Tomazos added the comment: After studying the include directives in the Include folder, I think the best fix would be: In Include/cpython/state.h: - #include "cpython/initconfig.h" + #include "initconfig.h" this will mean that state.h will find initc

[issue40642] Cpython "pystate.h" subdirectory wrong

Andrew Tomazos added the comment: Related: https://stackoverflow.com/q/63211981/1131467 -- ___ Python tracker ___ ___

[issue40642] Cpython "pystate.h" subdirectory wrong

Andrew Tomazos added the comment: The problem occurs if you: #include on *nix systems. Note `/usr/include/` is in the system include path. One workaround is to `-I/usr/include/python3.8` and then `#include `. Another workaround is to comment out: // #include "cp

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

STINNER Victor added the comment: New changeset 4a6bf276ed3e6687394afe26b0d9a061ac06fc6b by Nicholas Sim in branch 'master': bpo-35134: Move non-limited C API files to Include/cpython/ (GH-24561) https://github.com/python/cpython/commit/4a6bf276ed3e6687394afe26b0d9a061ac06fc6b

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Change by Nicholas Sim : -- pull_requests: +23342 pull_request: https://github.com/python/cpython/pull/24561 ___ Python tracker <https://bugs.python.org/issue35

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

STINNER Victor added the comment: New changeset 366dc3a1354078e38808b9c16276e97cca5b8aaf by Nicholas Sim in branch 'master': bpo-35134: Move Include/{pyarena.h,pyctype.h} to Include/cpython/ (GH-24550) https://github.com/python/cpython/commit/366dc3a1354078e38808b9c16276e97cca5b8aaf

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Change by Nicholas Sim : -- pull_requests: +2 pull_request: https://github.com/python/cpython/pull/24550 ___ Python tracker <https://bugs.python.org/issue35

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

STINNER Victor added the comment: New changeset 17dbd4078b68db8954df6b5cdc40b786bc4ad7af by Nicholas Sim in branch 'master': bpo-35134, Include: Move pytime.h to cpython/pytime.h (GH-23988) https://github.com/python/cpython/commit/17dbd4078b68db8954df6b5cdc40b786bc4ad7af

[issue41028] Move docs.python.org language and version switcher out of cpython

Ned Deily added the comment: @mdk, This seems to be working great for the the python.org doc builds. What do you think about backporting this to the current active branches so that the doc builds for individual releases and those included with binary installers show the new generic links

[issue42804] Unable to compile the cpython code x86 windows

Sunny added the comment: Got it fixed with following the below steps a. Delete external folder b. Run the below build command build.bat -k -E -p x64 -k killed the existing python build process -E skipped the external libraries fetching -p mentioned the platform closing the ticket as it

[issue40052] Incorrect pointer alignment in _PyVectorcall_Function() of cpython/abstract.h

Change by Petr Viktorin : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[ANN] Austin -- CPython frame stack sampler v2.1.1 is now available

I am delighted to announce the release 2.1.1 of Austin. If you haven't heard of Austin before, it is an open-source frame stack sampler for CPython, distributed under the GPLv3 license. It can be used to obtain statistical profiling data out of a running Python application without a single line

[ANN] Austin -- CPython frame stack sampler v2.1.1 is now available

I am delighted to announce the release 2.1.1 of Austin. If you haven't heard of Austin before, it is an open-source frame stack sampler for CPython, distributed under the GPLv3 license. It can be used to obtain statistical profiling data out of a running Python application without a single line

[issue40052] Incorrect pointer alignment in _PyVectorcall_Function() of cpython/abstract.h

Petr Viktorin added the comment: New changeset 187f76def8a5bd0af7ab512575cad30cfe624b05 by Petr Viktorin in branch '3.8': [3.8] bpo-40052: Fix alignment issue in PyVectorcall_Function() (GH-23999) (GH-24120) https://github.com/python/cpython/commit/187f76def8a5bd0af7ab512575cad30cfe624b05

[issue40052] Incorrect pointer alignment in _PyVectorcall_Function() of cpython/abstract.h

Change by Petr Viktorin : -- pull_requests: +22951 pull_request: https://github.com/python/cpython/pull/24120 ___ Python tracker <https://bugs.python.org/issue40

[issue40052] Incorrect pointer alignment in _PyVectorcall_Function() of cpython/abstract.h

Petr Viktorin added the comment: New changeset 6e72ab909de58e89b5a7cd6899587e203cf129a3 by Miss Islington (bot) in branch '3.9': [3.9] bpo-40052: Fix alignment issue in PyVectorcall_Function() (GH-23999) (GH-24005) https://github.com/python/cpython/commit

[issue42804] Unable to compile the cpython code x86 windows

Steve Dower added the comment: If we can solve it, that would be better. The access denied error looks a bit like a build process (or previous Python build?) is still running that has locked one of the files. Restarting the PC is the easiest way to make sure nothing is using them, or you

[issue42804] Unable to compile the cpython code x86 windows

Zachary Ware added the comment: It seems possible that the fetch of the Tcl/Tk binaries failed somehow; you can try removing the entire `externals` directory (or just anything in it that includes `tcl` or `tk`); you can use `PCbuild\get_externals.bat --clean` to do so. --

[issue42804] Unable to compile the cpython code x86 windows

Terry J. Reedy added the comment: >From the evidence presented, the problem building 3.8 on Win 10 is not with >our build code. I therefore believe that this should be closed as '3rd-party' >and that Sunny should inquire on python-list about the permission problem. >However, I marked this

[issue42804] Unable to compile the cpython code x86 windows

Sunny added the comment: I am running using admin rights but still getting the error -- ___ Python tracker ___ ___

[issue42804] Unable to compile the cpython code x86 windows

Bharath Posa added the comment: I just ran the file but got the below error saying permission denied PermissionError: [WinError 5] Access is denied: 'E:\\Libarary\\workspace\\python_dev\\cpython\\PCbuild\\..\\externals\\cpython-bin-deps-tcltk-8.6.9.0' -> 'E:\\Libarary\\worksp

[issue42804] Unable to compile the cpython code x86 windows

Dennis Sweeney added the comment: Were you able to run PCbuild\get_externals.bat ? -- ___ Python tracker ___ ___ Python-bugs-list

[issue42804] Unable to compile the cpython code x86 windows

Bharath Posa added the comment: Followed the instructions as per the link https://devguide.python.org/setup/#setup While running the command build.bat -- ___ Python tracker

[issue42804] Unable to compile the cpython code x86 windows

Dennis Sweeney added the comment: What commands did you enter? Are you following the instructions at https://devguide.python.org/setup/ ? -- nosy: +Dennis Sweeney ___ Python tracker

[issue42804] Unable to compile the cpython code x86 windows

Change by Bharath Posa : -- title: Unable to compile the code x86 windows -> Unable to compile the cpython code x86 windows type: -> compile error ___ Python tracker <https://bugs.python.org/i

[issue40052] Incorrect pointer alignment in _PyVectorcall_Function() of cpython/abstract.h

Change by miss-islington : -- pull_requests: +22847 pull_request: https://github.com/python/cpython/pull/24005 ___ Python tracker <https://bugs.python.org/issue40

[issue40052] Incorrect pointer alignment in _PyVectorcall_Function() of cpython/abstract.h

miss-islington added the comment: New changeset 056c08211b402b4dbc1530a9de9d00ad5309909f by Petr Viktorin in branch 'master': bpo-40052: Fix alignment issue in PyVectorcall_Function() (GH-23999) https://github.com/python/cpython/commit/056c08211b402b4dbc1530a9de9d00ad5309909f

[issue40052] Incorrect pointer alignment in _PyVectorcall_Function() of cpython/abstract.h

Change by Petr Viktorin : -- nosy: +petr.viktorin nosy_count: 4.0 -> 5.0 pull_requests: +22841 pull_request: https://github.com/python/cpython/pull/23999 ___ Python tracker <https://bugs.python.org/issu

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Serhiy Storchaka added the comment: Victor, could you please add README files in directories cpython and internals? It is not clear what headers are considered more private. -- ___ Python tracker <https://bugs.python.org/issue35

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Change by Nicholas Sim : -- nosy: +nw0 nosy_count: 6.0 -> 7.0 pull_requests: +22830 pull_request: https://github.com/python/cpython/pull/23988 ___ Python tracker <https://bugs.python.org/issu

[issue42734] "bogus_code_obj.py" should be removed from "cPython/Lib/test/crashers"

Serhiy Storchaka added the comment: No, it was not fixed. The code object creation was broken, because the code constructor signature was changed. -- nosy: +serhiy.storchaka ___ Python tracker

[issue42734] "bogus_code_obj.py" should be removed from "cPython/Lib/test/crashers"

l status: open title: "bogus_code_obj.py" should be removed from "cPython/Lib/test/crashers" type: enhancement versions: Python 3.10, Python 3.8, Python 3.9 ___

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Okay, well at least now googling Python + "A dynamic link library (DLL) initialization routine failed." give something which could point a user may be able to identify the issue. It wasn't obvious to me that imports did not hold the GIL, but it is clear in

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: I doubt there's anything more we can do about Windows swallowing an access violation and turning it into a generic error. There's a very low chance you'd have found any notes about it in the docs, so this bug will probably stand as the best available reference

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: I found it. The change that hit JPype is https://bugs.python.org/issue33895 Thanks, Eryk Sun for figuring this out. I would never have gotten myself. -- ___ Python tracker

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Drat I missed that one when I was scanning for statics because I was focusing C++ resource rather than looking for Python resources. I also wouldn't have expected this to happen on only one platform, but that was my bad. Is it possible to improve the error

[issue42529] CPython DLL initialization routine failed from PYC cache file

Eryk Sun added the comment: I built JPype normally in release mode and was able to analyze the problem using the platform debugger (cdb or WinDbg). I think the issue is pretty straight forward. The static initializer for classMagic in "native\python\pyjp_class.cpp" is calling PyDict_New().

[issue42529] CPython DLL initialization routine failed from PYC cache file

ffer, buffer, stuff)) { -Py_FatalError("buffer overflow in getpathp.c's join()"); -} +if (FAILED(PathCchCombineEx(buffer, MAXPATHLEN+1, buffer, stuff, 0))) { +Py_FatalError("buffer overflow in getpathp.c's join()"); } } ``` Also given JPype is re

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: I will look through the list of samples in Detours to see if there is something that can give us better stacktrace information. If we really need a stack trace I can make Detours bust by creating an intentional segfault and see if we can attach the debugger

[issue42529] CPython DLL initialization routine failed from PYC cache file

t's not. > Does that point to anything we can use to solve this? It would be great to know what's calling FlsGetValue there. Obviously something within the CRT, since CPython doesn't use fibers anywhere. I guess it's probably some kind of locale settings that are only necessary when opening a file i

[issue42529] CPython DLL initialization routine failed from PYC cache file

William Pickard added the comment: I recommend first doing a capture of these functions first, incase Windows is routing some through them: LoadLibrary(Ex)(W|A) W is the Unicode variant while A is the Ascii variant. -- ___ Python tracker

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: I looked more at the logs to see if I can find out what to instrument next. The log files unfortunately don't diff well because every line contains a timestamp so I can't a proper alignment as well as all the real addresses. So I wrote a short program to

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Eryk, Unfortunately, this particular bug is resistant to attaching the debugger. Whenever the debugger is attached the bug disappears. Fortunately the suggestion to use Detours by WildCard65 appears to offer a way to diagnose the issue. --

[issue42529] CPython DLL initialization routine failed from PYC cache file

William Pickard added the comment: Msvcp140.dll from what I can find is part of the VS 2015 Redstributable package. -- ___ Python tracker ___

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: Looking at the winapi_thunks.cpp source file from the CRT, it may be that LCIDToLocaleName is failing to be loaded for some reason. That's the one that comes after LCMapStringEx, so if it's failing, that could abort the whole process. Alternatively,

[issue42529] CPython DLL initialization routine failed from PYC cache file

40.dll and dynamically linked. More likely to occur with msvcp140.dll in the mix, since CPython does not include it. I'm not seeing full paths for the dependent DLLs, so I have no way to know whether it's mixing and matching versions. CPython installs include vcruntime140.dll, which should be the one

[issue42529] CPython DLL initialization routine failed from PYC cache file

Eryk Sun added the comment: > ImportError: DLL load failed while importing _jpype: > A dynamic link library (DLL) initialization routine failed. With loader snaps enabled for python[_d].exe (i.e. loader debug messages), you can attach a debugger to discover which DLL's init routine is

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: The last libraries loaded prior to the failure were... ``` 20201218192451066 20440 50.60: trclnk64: api-ms-win-eventing-provider-l1-1-0.dll [7ffc4c974108 7ffc4c8b7808] 20201218192451066 20440 50.60: trclnk64: EventUnregister0 7ffc4eab37a0

[issue42529] CPython DLL initialization routine failed from PYC cache file

William Pickard added the comment: I was just expecting only detours for LoadLibraryExW (and variants) to find out which dll failed. -- ___ Python tracker ___

[issue42529] CPython DLL initialization routine failed from PYC cache file

e call before we load MSVCP140.dll. Unfortunately, I am way outside my element here as a Linux/Java/CPython programmer. My next guess would be to instrument the set system error and if we are within LoadLibrary then execute "int *i=0; *i=0;" and hope the debugger would get me the point o

[issue42529] CPython DLL initialization routine failed from PYC cache file

William Pickard added the comment: https://www.microsoft.com/en-us/research/project/detours/ -- ___ Python tracker ___ ___

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Can you be so kind as pointing me to a LoadLibraryExW detour example for Python? I have shimmed a DLL before to capture transaction logs in the past, but not with a Python or a system library. -- ___ Python

[issue42529] CPython DLL initialization routine failed from PYC cache file

William Pickard added the comment: You may need to inject a LoadLibraryExW detour into your python runtime before _jpype is loaded and output all the library names its requesting. You may need to detour all Load Library functions for maximum coverage. -- nosy: +WildCard65

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Just for reference here are all the dependencies that _jpype has ``` MSVCP140.dll python39.dll

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: I attempted another deep dive on this one. 1) Removed manual library add platform_specific['libraries'] = ['Advapi32'] No change. 2) Compared symbol wise imports Two imports changed PyIndex_Check PyObject_CheckBuffer plus one additional "fflush" dependency

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Well that gives me a place to search from. Unfortunately statics are not likely the source of the issue. I scrubbed all C++ structures from the project into a big structure which has only a single global pointer which I initialize in the init method. It

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: You'll find it leads up to a LoadLibraryExW call in Python/dynload_win.c that is failing with ERROR_DLL_INIT_FAILED (1114) in GetLastError(). From that point on, it's looking solely at _jpype.pyd and its dependencies, and it could be any of them failing to

[issue42529] CPython DLL initialization routine failed from PYC cache file

sers\\nelson85\\documents\\devel\\open\\jpype\\jpype\\__pycache__\\__init__.cpython-39.pyc' # extension module '_jpype' loaded from 'c:\\users\\nelson85\\documents\\devel\\open\\jpype\\_jpype.cp39-win_amd64.pyd' # extension module '_jpype' executed from 'c:\\users\\nelson85\\documents\\devel\\op

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Thanks, I will see if I can get additional diagnostics today. Otherwise I will have to start recompiling Python with diagnostic hooks. I have never had to rebuild python on windows so it may take a while to figure out how to make progress. The monkey patch

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: Monkeypatching native types looks suspect as anything, but probably not the cause here. Good luck :) So I checked some of our code around dynamic loads and it's got to be caused by the loader in our LoadLibrary call, not when we call your module init function.

[issue42529] CPython DLL initialization routine failed from PYC cache file

JPype gets built as an ordinary setup.py CPython module. So it is possibly a bug in the build pattern of the customizers in JPype that was exposed by Python 3.9. I am just going to cut and paste so that it is easy to follow along. jpype/setup.py ``` ... from setuptools import Extension ... impor

[issue42529] CPython DLL initialization routine failed from PYC cache file

as part of CPython should do anything interesting on load, at least nothing we can change/fix. So jpype will probably need an update to import something manually. The only thing I can think of that changed along these lines in 3.9.0 is that we no longer LoadLibrary("api-ms-win-core-path-l

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Any progress on this item? I am seeing additional reports of this error in the conda stream tracker and elsewhere. As it only occurs when the debugger is not hooked up I don't have much traction to make progress myself. --

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Oddly that was the only exception that I got. When I hit continue it proceeded without issue and the dll was loaded correctly. However, when I try without the debugger attached the error reappears. So this is one of those Schrodinger errors. I know the

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: Replicating also requires installing Java (I got as far as the build failing), which is going to have to wait until I have time to spin up a throwaway machine :) That exception is a normal part of the import process and should be being handled. It's not the

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: I managed to get the debugger attached (unfortunately I am not a windows programmer so I don't use these tools). It appears when loading from a pyc, it is attempting to open the directory as a Zip file which is throwing an exception resulting in a failure to

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

STINNER Victor added the comment: New changeset fe6e5e7cfd68eeaa69fd1511f354a1b4d8d90990 by Victor Stinner in branch 'master': bpo-35134: Add Include/cpython/pythonrun.h file (GH-23701) https://github.com/python/cpython/commit/fe6e5e7cfd68eeaa69fd1511f354a1b4d8d90990

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

Change by STINNER Victor : -- pull_requests: +22568 pull_request: https://github.com/python/cpython/pull/23701 ___ Python tracker <https://bugs.python.org/issue35

[issue40652] Test test_locale failed when running cpython test on Windows 10 x64 for version 3.9.0a6+

Change by Terry J. Reedy : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> [Windows] locale.getdefaultlocale() issues on Windows: test_locale.test_getsetlocale_issue1813() ___ Python tracker

[issue42579] Solution from gh#python/cpython#13236 unnecessarily binds building of documentation to the latest version of Sphinx

Pablo Galindo Salgado added the comment: New changeset b63a620014b67a6e63d10783149c41baaf59def8 by Matěj Cepl in branch 'master': bpo-42579: Make workaround for various versions of Sphinx more robust (GH-23662) https://github.com/python/cpython/commit/b63a620014b67a6e63d10783149c41baaf59def8

[issue42579] Solution from gh#python/cpython#13236 unnecessarily binds building of documentation to the latest version of Sphinx

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue42579] Solution from gh#python/cpython#13236 unnecessarily binds building of documentation to the latest version of Sphinx

Change by Ned Deily : -- nosy: +mdk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42579] Solution from gh#python/cpython#13236 unnecessarily binds building of documentation to the latest version of Sphinx

Change by Matej Cepl : -- keywords: +patch pull_requests: +22529 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23662 ___ Python tracker <https://bugs.python.org/issu

[issue42579] Solution from gh#python/cpython#13236 unnecessarily binds building of documentation to the latest version of Sphinx

New submission from Matej Cepl : I think the solution in gh#python/cpython#13236 is the suboptimal one, because it makes Python dependent on the latest version of Sphinx unnecessarily. There are many situations where Python can be built on the older platform and it is too bothersome

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: There really shouldn't be any difference between those two paths, apart from skipping the compile step in the second case. It sounds like you're pretty well set up for testing, so would you be able to try the test while running under either the Visual Studio

[issue42529] CPython DLL initialization routine failed from PYC cache file

s the same with and without loading from a pyc. It may be a change in the requirements of module initialization, but I don't know how to proceed. There was one deprecation warning but correcting that did not alter the outcome. It appears that the execute path for importing a CPython module takes a

[issue42322] Spectre mitigations in CPython interpreter

Serhiy Storchaka added the comment: AFAIK Spectre attacks rely on precise time measures. But Python is very far from bare hardware. Pure Python code is 10-100 times slower than compiled C or jitted JavaScript, and the variance is high, so it is hard to get stable results in benchmarks.

[issue42322] Spectre mitigations in CPython interpreter

STINNER Victor added the comment: You can try to use a C compiler which implements workarounds, but I don't think that anything should be done directly in CPython. -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue42

[issue42322] Spectre mitigations in CPython interpreter

New submission from Amir Naseredini : I was looking up everywhere and could not find any mitigations for Spectre attack by a Python interpreter(CPython)! I don't know if my question is correct or how feasible it is, but does anyone know if there are any mitigations for different variants

[issue41028] Move docs.python.org language and version switcher out of cpython

Julien Palard added the comment: New changeset ee2549c2ba8bae00f2b2fea8a39c6dfbd1d06520 by Julien Palard in branch 'master': bpo-41028: Doc: Move switchers to docsbuild-scripts. (GH-20969) https://github.com/python/cpython/commit/ee2549c2ba8bae00f2b2fea8a39c6dfbd1d06520

<    1   2   3   4   5   6   7   8   9   10   >