It appears that somewhere between Python 2.5 and Python 2.6, some socket
constants were lost in Windows builds.

Python 2.6.2 (r262:71605, Apr 14 2009, 22:46:50) [MSC v.1500 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket; socket.IPPROTO_IPV6
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'IPPROTO_IPV6'

Confirmed this problem on 32-bit builds and Python 3.1.1 also. I suspect
the compiler upgrade influenced this behavior.

Let me know if I can help track down the issue.

This comment from the MSDN docs may be relevant:

On the Microsoft Windows Software Development Kit (SDK) released for
Windows Vista and later, the organization of header files has changed
and IPPROTO_IPV6 level is defined in the Ws2def.h header file which is
automatically included in the Winsock2.h header file. The IPPROTO_IPV6
socket options are defined in the Ws2ipdef.h header file which is
automatically included in the Ws2tcpip.h header file. The Ws2def.h and
Ws2ipdef.h header files should never be used directly.

I think I found the problem.

It appears Python is compiled with 

#define _WIN32_WINNT 0x0500

But IPPROTO_IPV6 (and other constants) are only defined

#if(_WIN32_WINNT >= 0x0501)

What's the proper fix for this issue?

I think a suitable test case for this issue is:

if hasattr(sys, 'getwindowsversion'):
  if sys.getwindowsversion() >= (5,1):
    assert hasattr(socket, 'IPPROTO_IPV6')

Tried against 2.5.5, 2.6.4, 2.7a3 and 3.1.1, all seem to fail.

In PC/pyconfig.h we #define Py_WINVER to _WIN32_WINNT_WIN2K  (0x500)  for 32bit builds.

I think we should update this to _WIN32_WINNT_WINXP  (0x501)  for all builds, not just 64bit.

Assigning to loewis as he does our windows release builds so likely knows what the ramifications of this would be.

Bumping the API level to XP might mean that we stop supporting Windows 2000; I'm not sure whether we agreed to that yet.

I'd be curious to find out why the constants were defined in Python 2.5.

"extended support" for windows 2000 server ends in a few months, mainstream support ended 5 years ago:

 http://support.microsoft.com/lifecycle/?LN=en-us&x=8&y=9&p1=7274

That, IMNSHO, implies that python 2.7 and 3.2 should not bother supporting win2k.

Regardless, I'd imagine we can look the particular constants in question up and hard code the values when the header files don't define them for us (that is also the obvious workaround for anyone needing them in code today).

Following the python-dev consensus, I have now added a warning to the 2.7 installer that this will be the last release supporting Windows 2000.

I still think that we should not bump the SDK version above 500 for 2.7. Changing the SDK level does *not just* enable new API functions and constants, it may also change the layout of structures, causing applications to break on earlier systems (see the desaster with SystemParametersInfo, #1601). Bumping the version for 3.2 is fine.

Should this be fixed before the final release?

IMNSHO it should but that would violate our release practices to do it this late in the cycle.  I expect the release manager to decline.

It isn't a critical issue, the end result is that people will hard code the constants into their own code themselves since we don't have them in the library yet.

I would consider it to be regression and bugfix that is not inappropriate to repair at this point.

> I would consider it to be regression and bugfix that is not inappropriate to repair at this point.

I'd also be in favor of fixing it. To reduce the risk of breaking
something, I'd only raise socketmodule to a more recent Windows API.
Of course, this, in itself, might also break something.