classification
Title: socket lib beahavior change in 3.6.4
Type: behavior Stage: resolved
Components: Library (Lib), Windows Versions: Python 3.8, Python 3.7, Python 3.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: steve.dower Nosy List: Ma Lin, asvetlov, inada.naoki, miss-islington, ned.deily, njs, paul.moore, skn78, steve.dower, thatiparthy, tim.golden, tjguk, zach.ware
Priority: release blocker Keywords: 3.6regression, patch

Created on 2017-12-21 00:12 by skn78, last changed 2018-02-26 19:00 by steve.dower. This issue is now closed.

Files
File name Uploaded Description Edit
winsdk_watchdog.py Ma Lin, 2018-02-09 00:57
Pull Requests
URL Status Linked Edit
PR 5468 closed Ma Lin, 2018-02-01 08:53
PR 5523 merged Ma Lin, 2018-02-04 01:39
PR 5585 merged Ma Lin, 2018-02-08 00:37
PR 5910 open miss-islington, 2018-02-26 18:11
Messages (49)
msg308837 - (view) Author: Kamil (skn78) Date: 2017-12-21 00:12
On Windows, python 3.6.3 code "hasattr(socket, 'TCP_KEEPCNT')" gives False, python 3.6.4 gives True. This behavior breaks many libraries that i use.
msg308864 - (view) Author: Srinivas Reddy Thatiparthy(శ్రీనివాస్ రెడ్డి తాటిపర్తి) (thatiparthy) * Date: 2017-12-21 09:56
dtdev@dtdev-centos $ python3
Python 3.6.3 (default, Oct 11 2017, 18:17:01) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-18)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> hasattr(socket, 'TCP_KEEPCNT')
True
>>> 

I have linux system. Above is the output i got.
msg308883 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-12-21 16:59
Which libraries break? And which version of Windows are you running on?

If TCP_KEEPCNT was only added recently (perhaps in an SDK update) then it may not really be available on all versions.

(+Ned for awareness of the regression - not sure we need to respin immediately, but let's figure it out asap)
msg308885 - (view) Author: TJG (tjguk) Date: 2017-12-21 17:09
It's a compile-time option in socketmodule.c.

https://github.com/python/cpython/blob/3.6/Modules/socketmodule.c#L7466

The MSDN page suggests that it was added for Win10:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms738596(v=vs.85).aspx

Is it possible that the build machine has changed its OS/SDK between 
building 3.6.3 and 3.6.4?
msg308888 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-12-21 17:24
Yeah, I updated the build machine before doing 3.6.4rc1 (I never update between rc and final releases). I'm intrigued to see why it breaks libraries though - typically unsupported enum values like this are silently ignored on older Windows versions.
msg308900 - (view) Author: Kamil (skn78) Date: 2017-12-21 20:06
My OS version is Windows 7 x64.
I ran the script on the same computer, but with different versions of the python:

import socket
import platform

print('1) OS Info: ', platform.architecture(), platform.platform())
print('2) Python Info: ', platform.python_build(), platform.python_compiler())
print('3) TCP_KEEPCNT = ', hasattr(socket, 'TCP_KEEPCNT') )

Result for python 3.6.3:
1) OS Info:  ('64bit', 'WindowsPE') Windows-7-6.1.7601-SP1
2) Python Info:  ('v3.6.3:2c5fed8', 'Oct  3 2017 18:11:49') MSC v.1900 64 bit (AMD64)
3) TCP_KEEPCNT =  False

Result for python 3.6.4:
1) OS Info:  ('64bit', 'WindowsPE') Windows-7-6.1.7601-SP1
2) Python Info:  ('v3.6.4:d48eceb', 'Dec 19 2017 06:54:40') MSC v.1900 64 bit (AMD64)
3) TCP_KEEPCNT =  True
msg308901 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-12-21 20:21
Yes, I recognise that the change happened. I don't understand what breaks as a result.

You said it breaks "many libraries" - can you name some of them and provide sample code?
msg308902 - (view) Author: Kamil (skn78) Date: 2017-12-21 20:44
websocket-client 0.44.0
https://pypi.python.org/pypi/websocket-client/0.44.0

My script gives the following Erroe:

  File "C:\Program Files\Python36\lib\site-packages\websocket\_http.py", line 108, in _open_socket
    sock.setsockopt(*opts)
OSError: [WinError 10042] Для вызова getsockopt или setsockopt был указан неизвестный, недопустимый или неподдерживаемый параметр
или уровень
msg308904 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-12-21 21:13
Okay, so it looks like we don't have any prior art to conditionally omit constants from _socket based on OS level, and nothing in the setsockopt() doc suggests that it may fail like this.

So we either need to explicitly exclude this symbol on Windows (at least until we drop support for pre-Windows 10 versions) or silently ignore setsockopt errors for future good arguments. I'm inclined to do the former - other opinions?
msg308906 - (view) Author: TJG (tjguk) Date: 2017-12-21 21:43
Excluding for now seems like a simple option. (Basically a reversion to 
previous behaviour). And allows us easily to include again later easily.

Messing with setsockopt seems a little more risky.

In short: I'm with you -- exclude for now.
msg308943 - (view) Author: Kamil (skn78) Date: 2017-12-22 23:20
I suggest inserting the following code into socket.py:

if hasattr(sys, 'getwindowsversion') and sys.getwindowsversion()[0] < 10:
    del socket.TCP_KEEPCNT
    del socket.TCP_FASTOPEN
msg311172 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-01-29 21:15
Steve, is there something to be done here for 3.7.0?
msg311197 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-01-29 23:10
I like Kamil's suggestion.
msg311400 - (view) Author: Ma Lin (Ma Lin) * Date: 2018-02-01 02:47
Base on Kamil's code, a little improvements.


if hasattr(sys, 'getwindowsversion'):
    WIN_MAJOR, _, WIN_BUILD, *_ = sys.getwindowsversion()
    if WIN_MAJOR == 10:
        if WIN_BUILD >= 15063:    # Windows 10 1703
            pass
        elif WIN_BUILD >= 14393:  # Windows 10 1607
            del socket.TCP_KEEPCNT
        else:
            del socket.TCP_KEEPCNT
            del socket.TCP_FASTOPEN
    elif WIN_MAJOR < 10:
        del socket.TCP_KEEPCNT
        del socket.TCP_FASTOPEN


Windows 10 versions:
https://technet.microsoft.com/en-us/windows/release-info.aspx
msg311401 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-02-01 03:12
Nice. Think you can turn that into a pull request on GitHub?
msg311414 - (view) Author: Ma Lin (Ma Lin) * Date: 2018-02-01 10:04
So we either need to explicitly exclude this symbol on Windows (at least until we drop support for pre-Windows 10 versions) or silently ignore setsockopt errors for future good arguments. I'm inclined to do the former - other opinions?
--------------
I'm not a socket expert, I have a question about the former one.

Imagine someone changed those values in his/her code, for example:
socket.TCP_KEEPCNT = 20

His/her code works fine on new version Windows. Will this line break things again on old version Windows?
msg311465 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-02-01 20:34
Yes, adding the member back will put you back in the broken state, but there's nothing we can do to stop it.

Thanks for the PR - I'll take a look, and if I'm able to log into GitHub on my phone maybe finish it.
msg311466 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-02-01 20:37
PR looks good to me. Unfortunately without SMS (I'm travelling) I can't get into my account from my phone, so if someone else wants to add the backport tags (3.7 and 3.6) and finish it then feel free.
msg311487 - (view) Author: Ma Lin (Ma Lin) * Date: 2018-02-02 09:47
Glad to see PR 5468 not merged, I found it makes socket.py complicated.

Now I'm inclined to patch the code in PyInit__socket(void) of socketmodule.c
https://github.com/python/cpython/blob/3.6/Modules/socketmodule.c#L6504

There already has a MS-Windows version checking
https://github.com/python/cpython/blob/3.6/Modules/socketmodule.c#L6511

In there, we can use GetVersionEx instead of GetVersion to get BuildNumber, then delete unusable opinions.

(I don't have enough skill to modify .c code)
msg311502 - (view) Author: Kamil (skn78) Date: 2018-02-02 16:19
I suggest inserting the following code into socketmodule.c:

CHANGE:
#ifdef  TCP_KEEPCNT    
        PyModule_AddIntMacro(m, TCP_KEEPCNT);
#endif

TO:
#ifdef  TCP_KEEPCNT    
    #if defined(_MSC_VER) && _MSC_VER >= 1800
    // Windows 10 1703 (15063)
    if (IsWindows10CreatorsOrGreater()) {
        PyModule_AddIntMacro(m, TCP_KEEPCNT);        
    }
    #endif
#endif

AND CHANGE:
#ifdef  TCP_FASTOPEN
        PyModule_AddIntMacro(m, TCP_FASTOPEN);
#endif

TO:
#ifdef  TCP_FASTOPEN
    #if defined(_MSC_VER) && _MSC_VER >= 1800
    // Windows 10 1703 (Build: 14393)
    if (IsWindows10AnniversaryOrGreater()) {
        PyModule_AddIntMacro(m, TCP_FASTOPEN);
    }
    #endif 
#endif
msg311505 - (view) Author: Kamil (skn78) Date: 2018-02-02 16:31
With сorrect comments:
CHANGE:
#ifdef  TCP_KEEPCNT    
        PyModule_AddIntMacro(m, TCP_KEEPCNT);
#endif

TO:
#ifdef  TCP_KEEPCNT    
    #if defined(_MSC_VER) && _MSC_VER >= 1800
    if (IsWindows10CreatorsOrGreater()) { //Windows 10 1703(Build:15063 )
        PyModule_AddIntMacro(m, TCP_KEEPCNT);        
    }
    #endif
#endif

AND CHANGE:
#ifdef  TCP_FASTOPEN
        PyModule_AddIntMacro(m, TCP_FASTOPEN);
#endif

TO:
#ifdef  TCP_FASTOPEN
    #if defined(_MSC_VER) && _MSC_VER >= 1800
    if (IsWindows10AnniversaryOrGreater()) { //Windows 10 1607(Build: 14393)
        PyModule_AddIntMacro(m, TCP_FASTOPEN);
    }
    #endif 
#endif
msg311506 - (view) Author: Kamil (skn78) Date: 2018-02-02 16:42
I am sorry, this is the right version
CHANGE:
#ifdef  TCP_KEEPCNT    
        PyModule_AddIntMacro(m, TCP_KEEPCNT);
#endif

TO:
#ifdef  TCP_KEEPCNT    
    #ifdef MS_WINDOWS
    #if defined(_MSC_VER) && _MSC_VER >= 1800
    //on Windows avaible only from Windows 10 1703 (Build:15063 )
     if (IsWindows10CreatorsOrGreater()) {
         PyModule_AddIntMacro(m, TCP_KEEPCNT);        
     }    
    #else
     PyModule_AddIntMacro(m, TCP_KEEPCNT); 
    #endif
#endif

AND CHANGE:
#ifdef  TCP_FASTOPEN
        PyModule_AddIntMacro(m, TCP_FASTOPEN);
#endif

TO:
#ifdef  TCP_FASTOPEN
    #ifdef MS_WINDOWS
    #if defined(_MSC_VER) && _MSC_VER >= 1800
    //on Windows avaible only from Windows 10 1607(Build: 14393)
     if (IsWindows10AnniversaryOrGreater()) {
         PyModule_AddIntMacro(m, TCP_FASTOPEN);
     }
    #else
     PyModule_AddIntMacro(m, TCP_FASTOPEN);
    #endif 
#endif
msg311580 - (view) Author: Ma Lin (Ma Lin) * Date: 2018-02-04 01:50
I create a new one (PR 5523), I'm not a C & socket expert, so if you want to improve/polish the patch, feel free to create a new PR based on (or not) it.
msg311619 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2018-02-04 20:24
We don't remove unsupported socket flags on Unix, why should we do it for Windows?
msg311620 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2018-02-04 20:28
Socket constants a compile time values, obviously concrete operation system might not support a flag -- but we do nothing with it in runtime.

All flags available on compile time are exposed, it's true for modules like socket, os, select etc.
msg311621 - (view) Author: Nathaniel Smith (njs) * (Python committer) Date: 2018-02-04 21:52
The other option would be to always hide the new constant on Windows in 3.6, and make it unconditionally available on 3.7.
msg311641 - (view) Author: Ma Lin (Ma Lin) * Date: 2018-02-05 03:47
> We don't remove unsupported socket flags on Unix, why should we do it for Windows?

We have this problem because: compile with new Windows SDK, but run on old version Windows.
On Linux/Unix, the compile-time headers always consist with the system, so there should not has this problem.
Correct me if I'm wrong.

> The other option would be to always hide the new constant on Windows in 3.6, and make it unconditionally available on 3.7.

Search on GitHub [1], most people only check whether `socket` has such flags, like this:
if hasattr(socket, "TCP_KEEPCNT"):
    ...
    
Most of they don't check platform or Python version, so I'm -1 on this option.

-----------------
TCP_KEEPIDLE and TCP_KEEPINTVL were added in Windows 10 1709. [2]
The master branch on AppVeyor is using 10.0.16229 (1709) SDK. [3]
While 3.6 branch is using 10.0.15062 (1703) SDK. [4]
If you agree the way of PR 5523, maybe we should remove these two flags as well.

[1] https://github.com/search?l=Python&p=1&q=TCP_KEEPCNT&type=Code&utf8=%E2%9C%93
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms738596.aspx
[3] https://github.com/isuruf/cpython/blob/master/PCbuild/python.props#L78
[4] https://github.com/isuruf/cpython/blob/3.6/PCbuild/python.props#L77
msg311642 - (view) Author: INADA Naoki (inada.naoki) * (Python committer) Date: 2018-02-05 04:11
> On Linux/Unix, the compile-time headers always consist with the system, so there should not has this problem.
> Correct me if I'm wrong.

No.  Compile-time and run-time system is not always consist.
Kernel version may be upgraded / downgraded after Python is built.
And header version may not be consistent with kernel version.

There are some cases that system may return error for unsupported setsockopt() on Linux.

So I think websocket-client should catch OSError for setsockopt.

But if there are many broken libraries in the world, it's considerable
that hide it on Python side.

Kamil said "This behavior breaks many libraries that i use."
But I saw only websocket-client.  How many other libraries?
msg311644 - (view) Author: INADA Naoki (inada.naoki) * (Python committer) Date: 2018-02-05 04:43
It seems Linux has TCP_KEEPCNT from very old ages and
just checking it's existence was OK for many years.
So I'm +0.5 on this Python-side fix.
msg311652 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2018-02-05 08:23
What's about other OS/flags?
Should we commit that every exposed socket flag is supported in runtime?
It looks like very heavy burden.

Or the issue is specific for TCP_KEEPCNT for Windows only?
msg311653 - (view) Author: INADA Naoki (inada.naoki) * (Python committer) Date: 2018-02-05 08:27
> What's about other OS/flags?
> Should we commit that every exposed socket flag is supported in runtime?
It looks like very heavy burden.

I agree with you.  It almost impossible.

> Or the issue is specific for TCP_KEEPCNT for Windows only?

As far as my understanding, Yes.  This issue is only for it.
msg311654 - (view) Author: Nathaniel Smith (njs) * (Python committer) Date: 2018-02-05 08:46
I definitely don't think we should get into the game of trying to guess which flags are supported at runtime and only exposing those. It's not as simple as keeping a table of OS versions -- which would be hard enough to get right -- but on Linux you can have things like vendor backports of features to old versions, or a new kernel that happens to have had a particular feature configured out of it. (For example, AFAIK some major cloud providers still use kernels that have had IPv6 support removed entirely.)
msg311658 - (view) Author: Ma Lin (Ma Lin) * Date: 2018-02-05 09:46
> Or the issue is specific for TCP_KEEPCNT for Windows only?

Four flags involved.
In this table, result column is search results from GitHub.

  keyword       available   result
TCP_FASTOPEN   win10 1607+   778
TCP_KEEPCNT    win10 1703+   3356
TCP_KEEPIDLE   win10 1709+   4820
TCP_KEEPINTVL  win10 1709+   3410

3.6 branch is using 1703 SDK, 3.7/3.8 branches are using 1709 SDK.

This discussion is beyond my knowledge, I keep watch.
msg311713 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2018-02-06 07:40
I suggest closing the issue as "won't fix": checking in runtime for only for TCP flags on Windows is a weird exception.
Checking all flags on all supported platforms is impossible.

Client libraries should process such situations themself.
msg311714 - (view) Author: Nathaniel Smith (njs) * (Python committer) Date: 2018-02-06 07:44
I'm sympathetic to the idea that we don't want to carry around these checks, but also to the idea that this caused a regression in a micro release and that's not cool. Hence the idea that maybe we should keep everything the way it is in 3.7, but disable the new constants in 3.6, so that it arrives as part of a major release.

OTOH it's been in 3.6 for like 6 weeks already so I guess a lot of the affected parties are already working around it.
msg311718 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2018-02-06 09:05
If the fix will land into 3.6 bugfix release only -- I can live with it, while the overall looks tricky.

Ned Deily, what do you think about?
msg311725 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-02-06 15:23
> Ned Deily, what do you think about?

I would like to have Steve's opinion.
msg311753 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-02-07 00:00
In this case I like the flags disappearing on older versions, just as they would if you built CPython on a version of Linux that didn't have the flags. The problem is that the Windows SDK always defines enum values for all Windows versions even if you are targeting an older version, as most APIs silently ignore unknown flags. Since there's no way to reliably remove the flags at build time, it'll have to be done at import time.

In Python, existence normally implies availability, so we should maintain that here, especially since this API raises errors with these flags.
msg311754 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-02-07 00:02
Oh, and checking Windows version is hard. Better for us to get it right than every single library to risk getting it wrong. (The code used in the second PR is not right - there are IsWindowsVersion* macros that are better.)
msg311774 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2018-02-07 08:04
Ok
msg311811 - (view) Author: Ma Lin (Ma Lin) * Date: 2018-02-08 00:38
Here is PR 5585 for 3.6 branch.

For 3.7+, I would suggest patch in socketmodule.c like this:

PyMODINIT_FUNC
PyInit__socket(void)
{
    PyObject *m, *has_ipv6;
    ...
    ...
    ...
+#ifdef MS_WINDOWS
+   return remove_unusable_flags(m);
+#else
    return m;
+#endif
}

In this way, we handle the flags in a separated function remove_unusable_flags(m).
It keeps both socket.py and socketmodule.c neat.

Timelines FYI:

3.6.5 candidate: 2018-03-12 (tenative)
3.6.5 final: 2018-03-26 (tentative)

3.7.0 beta 2: 2018-02-26
3.7.0 beta 3: 2018-03-26
3.7.0 beta 4: 2018-04-30

> What's about other OS/flags?
> Should we commit that every exposed socket flag is supported in runtime?
> It looks like very heavy burden.

I have an idea about this concern, I will post it after some experiments.
msg311858 - (view) Author: Ma Lin (Ma Lin) * Date: 2018-02-09 00:57
> What's about other OS/flags?
> Should we commit that every exposed socket flag is supported in runtime?
> It looks like very heavy burden.

Let alone run-time check. Flags only depend on .C code and the building SDK, therefore, for a certain official release (e.g. CPython 3.6.5), the flags are fixed.
Then it is possible to get a flag-snapshot of a certain official release.

I wrote a script to dump/compare these flags in some Windows related modules (written in C language), see attached file winsdk_watchdog.py.

Let me demonstrate how to use it:

> Comparing from A to B:
> A: 3.6.3 (v3.6.3:2c5fed8, Oct  3 2017, 18:11:49) [MSC v.1900 64 bit (AMD64)]
> B: 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)]
> 
> socket added 2 constants: {'TCP_KEEPCNT', 'TCP_FASTOPEN'}
> 
> Finished, 1 modules changed constants.

Comparing official 3.6.3 (1607 SDK) with official 3.6.4 (1703 SDK).
It caught the 2 flags lead to this issue.

> Comparing from A to B:
> A: 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)]
> B: 3.7.0b1 (v3.7.0b1:9561d7f, Jan 31 2018, 07:26:34) [MSC v.1900 64 bit (AMD64)]
> 
> _winapi added 15 constants: {'NORMAL_PRIORITY_CLASS', 'FILE_TYPE_DISK', 'IDLE_PRIORITY_C
> LASS', 'CREATE_DEFAULT_ERROR_MODE', 'CREATE_BREAKAWAY_FROM_JOB', 'FILE_TYPE_PIPE', 'FILE
> _TYPE_REMOTE', 'BELOW_NORMAL_PRIORITY_CLASS', 'DETACHED_PROCESS', 'FILE_TYPE_CHAR', 'REA
> LTIME_PRIORITY_CLASS', 'FILE_TYPE_UNKNOWN', 'ABOVE_NORMAL_PRIORITY_CLASS', 'CREATE_NO_WI
> NDOW', 'HIGH_PRIORITY_CLASS'}
> 
> socket added 3 constants: {'TCP_KEEPIDLE', 'TCP_KEEPINTVL', 'MSG_ERRQUEUE'}
> 
> mmap added 1 constants: {'ACCESS_DEFAULT'}
> 
> Finished, 3 modules changed constants.

Comparing official 3.6.4 (1703 SDK) with official 3.7.0b1 (1709 SDK).

_winapi added 15 constants, after searching on GitHub repository, we know they were added in 2 commits:
https://github.com/python/cpython/commit/b5d9e0811463f3b28ba355a9e0bee7f1682854e3#diff-c5f7cb301f3746a4c77e8bcd91d9f897
https://github.com/python/cpython/commit/b2a6083eb0384f38839d3f1ed32262a3852026fa#diff-c5f7cb301f3746a4c77e8bcd91d9f897
So they can be ignored.

socket added 3 constants.
After exploring, we know the 2 flags (TCP_KEEPIDLE, TCP_KEEPINTVL) were added by 1709 SDK, so we need to handle them during run-time as well.
Another new flag MSG_ERRQUEUE was also added by 1709 SDK, we need a socket expert decide what to do.

mmap added 1 constants.
It was added in:
https://github.com/python/cpython/commit/5a8a84b34fbc385bf112819fe3b65503e33a33fa#diff-a8a9c2d912381058181c8ffe496aa39b
Also ignore it.

This check is only needed after switching to a newer Windows SDK. As the file name, it's a watchdog of Windows SDK.

Some people build third-party-build by themselves, it's also possible to create a unittest, and teach it how to recognize flexible-flags (may be removed during run-time).

For example, a man builds CPython 3.7.0b1 with 1607 SDK (official 3.7.0b1 build with 1709 SDK), then he got a prompt like this:

> These flags are missing in socket module:
> 'TCP_KEEPCNT', 'TCP_FASTOPEN', 'TCP_KEEPIDLE', 'TCP_KEEPINTVL', 'MSG_ERRQUEUE'
> Maybe you are using a older SDK than official release's, or these flags are removed in this machine during run-time.

If he build CPython 3.7.0b1 with 1903 SDK in two years later, he may got prompt like this:

> Unknown flags appear in socket module:
> 'TCP_XXXXXX', 'TCP_YYYYYY', 'TCP_ZZZZZZ'
> They were added by newer Windows SDK, please make sure....
msg311972 - (view) Author: Ma Lin (Ma Lin) * Date: 2018-02-11 00:32
PR 5523 is prepared for master/3.7 branches.
PR 5585 is prepared for 3.6 branch.
msg312836 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-02-25 19:08
What's the status of this issue?  3.7.0b2 is tagging in 48 hours or so and 3.6.5rc1 is in less than 2 weeks.
msg312915 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2018-02-26 11:10
I think PRs could be merged
msg312941 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-02-26 18:10
New changeset 19e7d48ce89422091f9af93038b9fee075d46e9e by Steve Dower (animalize) in branch 'master':
bpo-32394: Remove some TCP options on old version Windows. (GH-5523)
https://github.com/python/cpython/commit/19e7d48ce89422091f9af93038b9fee075d46e9e
msg312942 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-02-26 18:13
New changeset 1278c21f5234477aab21531773d65ca7ebd1b81f by Steve Dower (animalize) in branch '3.6':
[3.6] bpo-32394: Remove some TCP options on older version Windows. (GH-5585)
https://github.com/python/cpython/commit/1278c21f5234477aab21531773d65ca7ebd1b81f
msg312943 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-02-26 18:14
Agreed. I've merged these (and Miss Islington should get the 3.7 backport when CI completes)
msg312944 - (view) Author: miss-islington (miss-islington) Date: 2018-02-26 18:36
New changeset 53d3f8a89971bac3d2f454ff9f923066ecc3a6d9 by Miss Islington (bot) in branch '3.7':
bpo-32394: Remove some TCP options on old version Windows. (GH-5523)
https://github.com/python/cpython/commit/53d3f8a89971bac3d2f454ff9f923066ecc3a6d9
History
Date User Action Args
2018-02-26 19:00:09steve.dowersetstatus: open -> closed
assignee: steve.dower
stage: backport needed -> resolved
2018-02-26 18:36:25miss-islingtonsetnosy: + miss-islington
messages: + msg312944
2018-02-26 18:14:31steve.dowersetresolution: fixed
messages: + msg312943
stage: patch review -> backport needed
2018-02-26 18:13:53steve.dowersetmessages: + msg312942
2018-02-26 18:11:19miss-islingtonsetpull_requests: + pull_request5680
2018-02-26 18:10:39steve.dowersetmessages: + msg312941
2018-02-26 11:10:32asvetlovsetmessages: + msg312915
2018-02-25 19:08:49ned.deilysetmessages: + msg312836
2018-02-11 00:32:20Ma Linsetmessages: + msg311972
2018-02-09 00:57:53Ma Linsetfiles: + winsdk_watchdog.py

messages: + msg311858
2018-02-08 00:38:31Ma Linsetmessages: + msg311811
2018-02-08 00:37:10Ma Linsetpull_requests: + pull_request5403
2018-02-07 08:04:04asvetlovsetmessages: + msg311774
2018-02-07 00:02:54steve.dowersetmessages: + msg311754
2018-02-07 00:00:01steve.dowersetmessages: + msg311753
2018-02-06 15:23:15ned.deilysetmessages: + msg311725
2018-02-06 09:05:54asvetlovsetmessages: + msg311718
2018-02-06 07:44:33njssetmessages: + msg311714
2018-02-06 07:40:56asvetlovsetmessages: + msg311713
2018-02-05 09:46:17Ma Linsetmessages: + msg311658
2018-02-05 08:46:55njssetmessages: + msg311654
2018-02-05 08:27:36inada.naokisetmessages: + msg311653
2018-02-05 08:23:55asvetlovsetmessages: + msg311652
2018-02-05 04:43:29inada.naokisetmessages: + msg311644
2018-02-05 04:11:33inada.naokisetnosy: + inada.naoki
messages: + msg311642
2018-02-05 03:47:21Ma Linsetmessages: + msg311641
2018-02-04 21:52:39njssetnosy: + njs
messages: + msg311621
2018-02-04 20:28:35asvetlovsetmessages: + msg311620
2018-02-04 20:24:35asvetlovsetnosy: + asvetlov
messages: + msg311619
2018-02-04 01:50:35Ma Linsetmessages: + msg311580
2018-02-04 01:39:45Ma Linsetpull_requests: + pull_request5352
2018-02-02 16:42:58skn78setmessages: + msg311506
2018-02-02 16:31:25skn78setmessages: + msg311505
2018-02-02 16:19:59skn78setmessages: + msg311502
2018-02-02 09:47:21Ma Linsetmessages: + msg311487
2018-02-01 20:37:58steve.dowersetmessages: + msg311466
versions: + Python 3.7, Python 3.8
2018-02-01 20:34:24steve.dowersetmessages: + msg311465
2018-02-01 10:04:22Ma Linsetmessages: + msg311414
2018-02-01 08:53:38Ma Linsetkeywords: + patch
stage: test needed -> patch review
pull_requests: + pull_request5294
2018-02-01 03:12:35steve.dowersetmessages: + msg311401
2018-02-01 02:47:55Ma Linsetnosy: + Ma Lin
messages: + msg311400
2018-01-29 23:10:20steve.dowersetmessages: + msg311197
2018-01-29 21:15:16ned.deilysetmessages: + msg311172
2017-12-22 23:20:38skn78setmessages: + msg308943
2017-12-21 21:43:55tjguksetmessages: + msg308906
2017-12-21 21:13:20steve.dowersetmessages: + msg308904
components: + Windows
2017-12-21 20:44:36skn78setmessages: + msg308902
2017-12-21 20:21:31steve.dowersetmessages: + msg308901
2017-12-21 20:06:42skn78setmessages: + msg308900
2017-12-21 17:24:20steve.dowersetmessages: + msg308888
2017-12-21 17:09:10tjguksetnosy: + tjguk
messages: + msg308885
2017-12-21 16:59:10steve.dowersetpriority: normal -> release blocker

nosy: + ned.deily
messages: + msg308883

keywords: + 3.6regression
stage: test needed
2017-12-21 11:02:32pitrousetnosy: + paul.moore, tim.golden, zach.ware, steve.dower
2017-12-21 09:56:14thatiparthysetnosy: + thatiparthy
messages: + msg308864
2017-12-21 00:12:44skn78create