msg261384 - (view) |
Author: Florian Roth (Florian Roth) |
Date: 2016-03-08 21:41 |
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. |
|
|
msg261390 - (view) |
Author: Steve Dower (steve.dower) *  |
Date: 2016-03-08 23:58 |
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? |
|
|
msg261402 - (view) |
Author: Florian Roth (Florian Roth) |
Date: 2016-03-09 08:11 |
Screenshot 2.7.9 and platform.win32_ver() |
|
|
msg261403 - (view) |
Author: Florian Roth (Florian Roth) |
Date: 2016-03-09 08:18 |
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. |
|
|
msg261404 - (view) |
Author: Florian Roth (Florian Roth) |
Date: 2016-03-09 08:29 |
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. |
|
|
msg261410 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2016-03-09 09:23 |
May be this is related to . |
|
|
msg261451 - (view) |
Author: Steve Dower (steve.dower) *  |
Date: 2016-03-09 17:08 |
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. |
|
|
msg261657 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2016-03-12 16:08 |
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 module detection of Windows Server https://hg.python.org/cpython/rev/9db5846f126d New changeset fabbfad67362 by Steve Dower in branch 'default': Issue #26513: Fixes platform module detection of Windows Server https://hg.python.org/cpython/rev/fabbfad67362 |
|
|
msg274022 - (view) |
Author: James Domingo (James Domingo) |
Date: 2016-08-31 14:31 |
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.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🔞55) [MSC v.1900 64 bit (AM D64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import platform >>> platform.release() '7' |
|
|
msg274314 - (view) |
Author: Steve Dower (steve.dower) *  |
Date: 2016-09-03 17:06 |
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+. |
|
|
msg275340 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2016-09-09 16:47 |
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 module detection of Windows Server https://hg.python.org/cpython/rev/67c50dd3fcea |
|
|
msg275341 - (view) |
Author: Steve Dower (steve.dower) *  |
Date: 2016-09-09 16:47 |
We now use 'product_type' on 3.5+ and 'product' on 2.7, so we should be good. |
|
|
msg277117 - (view) |
Author: Alex R. Hoyling (arhoyling) |
Date: 2016-09-21 09:50 |
| |
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 "", line 1, in 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. |
|
msg277119 - (view) |
Author: Alex R. Hoyling (arhoyling) |
Date: 2016-09-21 10:04 |
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 |
|
|
msg277166 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2016-09-21 16:10 |
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 |
|
|
msg278577 - (view) |
Author: Scott Leerssen (Scott.Leerssen) |
Date: 2016-10-13 13:51 |
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') >>> |
|
|
msg278597 - (view) |
Author: Steve Dower (steve.dower) *  |
Date: 2016-10-13 20:02 |
Did you get the fixed version from what will become 2.7.13? It doesn't get magically fixed in existing releases. |
|
|
msg278601 - (view) |
Author: Scott Leerssen (Scott.Leerssen) |
Date: 2016-10-13 20:15 |
I just assumed it was fixed based on the 2.7.12 release notes. I missed the comment on 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. |
|
|