bpo-43284: Update platform.win32_ver to use platform._syscmd_ver instead of sys.getwindowsversion().platform_version for determining accurate Windows version #25500
Conversation
Co-authored-by: Eryk Sun <eryksun@gmail.com>
|
I also noticed that try:
ints = map(int, l)
except ValueError:
strings = l
else:
strings = list(map(str, ints))The |
|
Are you suggesting to make the change in this PR itself? |
|
Yes, please. (They don't exist, but any tests for these cases would be breaking on your PR because you've reintroduced the call to that function.) |
|
Change applied. |
Co-authored-by: Steve Dower <steve.dower@microsoft.com>
|
I also noticed something that can cause naming conflicts later. In the function win32_ver the minor version is stored in a variable named |
|
If you'd like to make more changes, go ahead. Just let us know when it's ready. |
|
Ok |
|
PR is ready for reviewing and if applicable then merging. (No more commits will be made) |
|
Thanks @shreyanavigyan for the PR, and @zooba for merging it |
|
Thanks @shreyanavigyan for the PR, and @zooba for merging it |
|
GH-25523 is a backport of this pull request to the 3.9 branch. |
…s.getwindowsversion() (pythonGH-25500) The sys module uses the kernel32.dll version number, which can vary from the "actual" Windows version. Since the best option for getting the version is WMI (which is expensive), we switch back to launching cmd.exe (which is also expensive, but a lot less code on our part). sys.getwindowsversion() is not updated to avoid launching executables from that module. (cherry picked from commit 2a3f489) Co-authored-by: Shreyan Avigyan <shreyan.avigyan@gmail.com>
…s.getwindowsversion() (pythonGH-25500) The sys module uses the kernel32.dll version number, which can vary from the "actual" Windows version. Since the best option for getting the version is WMI (which is expensive), we switch back to launching cmd.exe (which is also expensive, but a lot less code on our part). sys.getwindowsversion() is not updated to avoid launching executables from that module. (cherry picked from commit 2a3f489) Co-authored-by: Shreyan Avigyan <shreyan.avigyan@gmail.com>
|
GH-25524 is a backport of this pull request to the 3.8 branch. |
…s.getwindowsversion() (GH-25500) The sys module uses the kernel32.dll version number, which can vary from the "actual" Windows version. Since the best option for getting the version is WMI (which is expensive), we switch back to launching cmd.exe (which is also expensive, but a lot less code on our part). sys.getwindowsversion() is not updated to avoid launching executables from that module. (cherry picked from commit 2a3f489) Co-authored-by: Shreyan Avigyan <shreyan.avigyan@gmail.com>
…s.getwindowsversion() (GH-25500) The sys module uses the kernel32.dll version number, which can vary from the "actual" Windows version. Since the best option for getting the version is WMI (which is expensive), we switch back to launching cmd.exe (which is also expensive, but a lot less code on our part). sys.getwindowsversion() is not updated to avoid launching executables from that module. (cherry picked from commit 2a3f489) Co-authored-by: Shreyan Avigyan <shreyan.avigyan@gmail.com>
…s.getwindowsversion() (pythonGH-25500) The sys module uses the kernel32.dll version number, which can vary from the "actual" Windows version. Since the best option for getting the version is WMI (which is expensive), we switch back to launching cmd.exe (which is also expensive, but a lot less code on our part). sys.getwindowsversion() is not updated to avoid launching executables from that module.
platform.win32_verderives the Windows version fromsys.getwindowsversion().platform_versionwhich in turn derives the version fromkernel32.dll(which can be of a different version than Windows itself). Therefore this PR updates theplatform.win32_verto determine the version using theplatformmodule's_syscmd_verprivate function to return an accurate version.More discussions are held at: https://bugs.python.org/issue43284
https://bugs.python.org/issue43284