platform.win32_ver() broken in 2.7.11

[FlorianRoth]

BPO	26513
Nosy	@pfmoore, @tjguk, @zware, @serhiy-storchaka, @zooba
Files	Screen Shot 2016-03-08 at 19.05.38.png Screen Shot 2016-03-08 at 18.51.32.png: Screenshot 2.7.11

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/zooba'
closed_at = <Date 2016-09-09.16:47:58.690>
created_at = <Date 2016-03-08.21:41:33.598>
labels = ['type-bug', 'OS-windows']
title = 'platform.win32_ver() broken in 2.7.11'
updated_at = <Date 2016-10-13.20:15:20.335>
user = 'https://bugs.python.org/FlorianRoth'

bugs.python.org fields:

activity = <Date 2016-10-13.20:15:20.335>
actor = 'Scott.Leerssen'
assignee = 'steve.dower'
closed = True
closed_date = <Date 2016-09-09.16:47:58.690>
closer = 'steve.dower'
components = ['Windows']
creation = <Date 2016-03-08.21:41:33.598>
creator = 'Florian Roth'
dependencies = []
files = ['42095', '42096']
hgrepos = []
issue_num = 26513
keywords = []
message_count = 18.0
messages = ['261384', '261390', '261402', '261403', '261404', '261410', '261451', '261657', '274022', '274314', '275340', '275341', '277117', '277119', '277166', '278577', '278597', '278601']
nosy_count = 10.0
nosy_names = ['paul.moore', 'tim.golden', 'python-dev', 'Scott.Leerssen', 'zach.ware', 'serhiy.storchaka', 'steve.dower', 'Florian Roth', 'James Domingo', 'arhoyling']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue26513'
versions = ['Python 2.7', 'Python 3.5', 'Python 3.6']

[FlorianRoth]

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.

[zooba]

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?

[FlorianRoth]

Screenshot 2.7.9 and platform.win32_ver()

[FlorianRoth]

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=0

I'll also check the 64bit version.

[FlorianRoth]

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.

[serhiy-storchaka]

May be this is related to bpo-19143.

[zooba]

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.

[python-dev]

New changeset 5564cf3ba523 by Steve Dower in branch '3.5':
Issue bpo-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 bpo-26513: Fixes platform module detection of Windows Server
https://hg.python.org/cpython/rev/9db5846f126d

New changeset fabbfad67362 by Steve Dower in branch 'default':
Issue bpo-26513: Fixes platform module detection of Windows Server
https://hg.python.org/cpython/rev/fabbfad67362

[JamesDomingo]

Per SilentGhost's request, reposting my message from bpo-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'

[zooba]

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

[python-dev]

New changeset aeb39d4475c5 by Steve Dower in branch '3.5':
Issue bpo-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 bpo-26513: Fixes platform module detection of Windows Server
https://hg.python.org/cpython/rev/67c50dd3fcea

[zooba]

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

[arhoyling]

|| 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
  3

This would cause platform.release() to output '7' instead of '2008ServerR2'.

I don't think this issue is resolved.

[arhoyling]

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

[python-dev]

New changeset 03f2c8fc24ea by Steve Dower in branch '2.7':
Issue bpo-26513: Use winver.product_type instead of .product
https://hg.python.org/cpython/rev/03f2c8fc24ea

[ScottLeerssen]

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:6d1b6a68f775, Dec  5 2015, 20:40:30) [MSC v.1500 64 bit (AMD64)] on win32
Type "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>python
Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:24:40) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.win32_ver()
('7', '6.1.7601', 'SP1', u'Multiprocessor Free')
>>>

[zooba]

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

[ScottLeerssen]

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.