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 R2 server shows:('7', '6.1.7601', 'SP1', u'Multiprocessor Free')which is wrong. Platform OS detection seems to be broken with version 2.7.11.

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?

Screenshot 2.7.9 and platform.win32_ver()

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.dropbox.com/sh/26vfz4f8jziv665/AACtkCNK-ypAtquKwglUVdqQa?dl=0I'll also check the 64bit version.

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 function.

May be this is related toissue19143.

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 tried to get `sys.getwindowsversion().platform_type`, when it should have been `platform`. (Possibly this was changed late during review, as I definitely tested on at least one server platform to verify... maybe it worked with the old fallback code and then once I made sure that we always set `platform` I removed the fallback without fixing the attribute.)The patch is simple enough - committing and merging branches is the hard part. When I get a few free minutes I'll fix the attribute.

New changeset5564cf3ba523 by Steve Dower in branch '3.5':Issue#26513: Fixes platform module detection of Windows Serverhttps://hg.python.org/cpython/rev/5564cf3ba523New changeset9db5846f126d by Steve Dower in branch '2.7':Issue#26513: Fixes platform module detection of Windows Serverhttps://hg.python.org/cpython/rev/9db5846f126dNew changesetfabbfad67362 by Steve Dower in branch 'default':Issue#26513: Fixes platform module detection of Windows Serverhttps://hg.python.org/cpython/rev/fabbfad67362

Per SilentGhost's request, reposting my message fromissue 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.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AM  D64)] on win32  Type "help", "copyright", "credits" or "license" for more information.  >>> import platform  >>> platform.release()  '2008ServerR2'However, the function in the latest release, Python 3.5.2, misidentifies the system as Windows 7:  C:\Users\jdoe\Documents\Python>python-3.5.2-embed-amd64\python.exe  Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AM  D64)] on win32  Type "help", "copyright", "credits" or "license" for more information.  >>> import platform  >>> platform.release()  '7'

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+.

New changesetaeb39d4475c5 by Steve Dower in branch '3.5':Issue#26513: Fixes platform module detection of Windows Serverhttps://hg.python.org/cpython/rev/aeb39d4475c5New changeset67c50dd3fcea by Steve Dower in branch 'default':Issue#26513: Fixes platform module detection of Windows Serverhttps://hg.python.org/cpython/rev/67c50dd3fcea

We now use 'product_type' on 3.5+ and 'product' on 2.7, so we should be good.

|| 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  Traceback (most recent call last):    File "<stdin>", line 1, in <module>  AttributeError: 'sys.getwindowsversion' object has no attribute 'product'  >>> sys.getwindowsversion().product_type  3This would cause `platform.release()` to output '7' instead of '2008ServerR2'.I don't think this issue is resolved.

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 system platform"},    {"service_pack", "Latest Service Pack installed on the system"},    {"service_pack_major", "Service Pack major version number"},    {"service_pack_minor", "Service Pack minor version number"},    {"suite_mask", "Bit mask identifying available product suites"},    {"product_type", "System product type"},    {0}};https://hg.python.org/cpython/file/2.7/Python/sysmodule.c

New changeset03f2c8fc24ea by Steve Dower in branch '2.7':Issue#26513: Use winver.product_type instead of .producthttps://hg.python.org/cpython/rev/03f2c8fc24ea

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>pythonPython 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:40:30) [MSC v.1500 64 bit (AMD64)] on win32Type "help", "copyright", "credits" or "license" for more information.>>>>>> import platform>>> platform.win32_ver()('2008ServerR2', '6.1.7601', 'SP1', u'Multiprocessor Free')>>>In 2.7.12 (incorrect)C:\Users\Administrator>pythonPython 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:24:40) [MSC v.1500 64 bit (AMD64)] on win32Type "help", "copyright", "credits" or "license" for more information.>>> import platform>>> platform.win32_ver()('7', '6.1.7601', 'SP1', u'Multiprocessor Free')>>>

Did you get the fixed version from what will become 2.7.13? It doesn't get magically fixed in existing releases.

I just assumed it was fixed based on the 2.7.12 release notes.  I missed the comment onmsg277117 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.