[issue26513] platform.win32_ver() broken in 2.7.11

Scott Leerssen added the comment: I just assumed it was fixed based on the 2.7.12 release notes. I missed the comment on msg277117 which describes the same problem, so clearly this is a known issue and I'll look forward to seeing the fix in 2.7.13. Thanks. -- ___

[issue26513] platform.win32_ver() broken in 2.7.11

Steve Dower added the comment: Did you get the fixed version from what will become 2.7.13? It doesn't get magically fixed in existing releases. -- ___ Python tracker ___ ___

[issue26513] platform.win32_ver() broken in 2.7.11

Scott Leerssen added the comment: It looks like there may still be an issue in Python 2.7.12 on Windows 2008 R2 (Datacenter Edition). On an Amazon instance (tried t2.micro and m4.large) we are seeing the following: In 2.7.11 (correct) C:\Users\Administrator>python Python 2.7.11 (v2.7.11:6d1b6

[issue26513] platform.win32_ver() broken in 2.7.11

Roundup Robot added the comment: New changeset 03f2c8fc24ea by Steve Dower in branch '2.7': Issue #26513: Use winver.product_type instead of .product https://hg.python.org/cpython/rev/03f2c8fc24ea -- ___ Python tracker

[issue26513] platform.win32_ver() broken in 2.7.11

Alex R. Hoyling added the comment: In fact, at the tip of the 2.7 branch in `sysmodule.c` we have: static PyStructSequence_Field windows_version_fields[] = { {"major", "Major version number"}, {"minor", "Minor version number"}, {"build", "Build number"}, {"platform", "Operating s

[issue26513] platform.win32_ver() broken in 2.7.11

Alex R. Hoyling added the comment: || We now use 'product_type' on 3.5+ and 'product' on 2.7, so we should be good. It actually looks like we use `product_type` on Python 2.7.12, not `product`. On Python 2.7.12, on Windows Server 2008 R2: >>> import sys >>> sys.getwindowsversion().product

[issue26513] platform.win32_ver() broken in 2.7.11

Steve Dower added the comment: We now use 'product_type' on 3.5+ and 'product' on 2.7, so we should be good. -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker ___

[issue26513] platform.win32_ver() broken in 2.7.11

Roundup Robot added the comment: New changeset aeb39d4475c5 by Steve Dower in branch '3.5': Issue #26513: Fixes platform module detection of Windows Server https://hg.python.org/cpython/rev/aeb39d4475c5 New changeset 67c50dd3fcea by Steve Dower in branch 'default': Issue #26513: Fixes platform m

[issue26513] platform.win32_ver() broken in 2.7.11

Steve Dower added the comment: I'll try and get to this during the week. I believe it's a fairly simple fix, though it will mean that platform.py diverges between 2.7 and 3.5+. -- resolution: fixed -> stage: resolved -> needs patch status: closed -> open __

[issue26513] platform.win32_ver() broken in 2.7.11

James Domingo added the comment: Per SilentGhost's request, reposting my message from issue 27890 here -- The platform.release() function in Python 3.5.1 returns the correct value on Windows 2008 Server R2: C:\Users\jdoe\Documents\Python>python-3.5.1-embed-amd64\python.exe Python 3.5.1 (v3

[issue26513] platform.win32_ver() broken in 2.7.11

Roundup Robot added the comment: New changeset 5564cf3ba523 by Steve Dower in branch '3.5': Issue #26513: Fixes platform module detection of Windows Server https://hg.python.org/cpython/rev/5564cf3ba523 New changeset 9db5846f126d by Steve Dower in branch '2.7': Issue #26513: Fixes platform modul

[issue26513] platform.win32_ver() broken in 2.7.11

Changes by Steve Dower : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-li

[issue26513] platform.win32_ver() broken in 2.7.11

Steve Dower added the comment: That's what I initially assumed, but when I looked in my 2.7 repo those changes weren't there. But according to the bug I checked them in, so I guess it is my fault. Looking at the diff (e.g. 2f57270374f7), it seems I got sucked in by following the old code that

[issue26513] platform.win32_ver() broken in 2.7.11

Serhiy Storchaka added the comment: May be this is related to issue19143. -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python

[issue26513] platform.win32_ver() broken in 2.7.11

Florian Roth added the comment: Confirmed. Version 2.7.11 64bit is erroneous too. Version 2.7.10 64bit works fine. I added the 64bit version screenshots to the shared dropbox folder. I'll downgrade all my projects to version 2.7.10 as the OS version detection is essential for proper functio

[issue26513] platform.win32_ver() broken in 2.7.11

Florian Roth added the comment: I tested it on two different Windows 2008 R2 server systems. Same results. And I checked the issue by uninstalling 2.7.11 and installed 2.7.9 and 2.9.10 to verify. This means that not the system itself can be the problem. Please see screenshots: https://www.dr

[issue26513] platform.win32_ver() broken in 2.7.11

Florian Roth added the comment: Screenshot 2.7.9 and platform.win32_ver() -- Added file: http://bugs.python.org/file42095/Screen Shot 2016-03-08 at 19.05.38.png ___ Python tracker _

[issue26513] platform.win32_ver() broken in 2.7.11

Steve Dower added the comment: Nothing has changed here as far as I'm aware. The part of platform.py in use here has potentially different behavior if you have pywin32 installed. Is that the case? Maybe you updated that as well or haven't installed it for 2.7.11 yet? -- _

[issue26513] platform.win32_ver() broken in 2.7.11

New submission from Florian Roth: Using Python 2.7.9 and 2.7.10 (32bit) on a Windows Server 2008 R2 64bit System platform.win32_ver() shows the following, which is correct: ('2008ServerR2', '6.1.7601', 'SP1', u'Multiprocessor Free') Using Python version 2.7.11 (32bit) on the same Windows 2008