GeezerVison

Hi @ammaraskar! I appreciate the level of work you've put into this. On the other hand, I wonder about the maintenance cost of updating this each time an OS gains support for one those options.
(also, the OS list by far not exhaustive, for example we would certainly want to add an OS X column -- or is it "macOS" these days?)

My personal take would be that people who use the (rather low-level) socket module should know how to check man pages and/or the MSDN documentation for the presence and meaning of specific options. Higher-level alternatives are the various networking frameworks (blocking or non-blocking) and the existing implementations of applicative protocols such as http.

Not sure what others think about this.

On the other hand, I wonder about the maintenance cost of updating this each time an OS gains support for one those options.

I think this will be far and in between, the core socket options are usually a fairly stable OS level API. With the current ones documented, it should hopefully encourage maintainers to document newly added ones and then check their availability accordingly.

As far as an OS gaining support, I think that will be fairly rare but in that case having the documentation being slightly outdated wouldn't be the worst of situations.

There is some older discussion about this on the bpo thread.

My personal take would be that people who use the (rather low-level) socket module should know how to check man pages and/or the MSDN documentation for the presence and meaning of specific options.

I agree, however there is no real documentation on what constants python exposes from the underlying socket library. At the very minimum I think documenting the list of options and brief descriptions of them would be a good idea. Short of doing dir(socket) there is no way to examine what is available.

Hi,

@pitrou you are right about the list of the options, we have to check in the official documentation (man pages or MSDN site) but this table with some references can be useful for the beginners, and also for the maintainer, because we can check if an option is directly supported by Python or not.

@ammaraskar
Maybe you could add "This list is incomplete exhaustive and you should to read the documentation of your operating system" and also, add a column for macOS.
But don't forget that we support some operating systems.

At the very least, I think adding documentation for the list of options that socketmodule exports and getsockopt/setsockopt would be useful. I agree that the compatibility table is a bit of a pain to maintain.

@ammaraskar How did you find the entries for your table. I propose another solution, for the most used entries, we could keep them in the tables. Add a small paragraph with the link to the official documentation of macOS, Windows and for the man pages for POSIX systems.

I pretty much just went down the list here:

Then I looked them up in the man page here for Linux: http://man7.org/linux/man-pages/man7/socket.7.html

FreeBSD here: https://www.freebsd.org/cgi/man.cgi?query=setsockopt&sektion=2&apropos=0&manpath=FreeBSD+7.0-RELEASE

and finally Windows here: https://docs.microsoft.com/en-us/windows/desktop/WinSock/sol-socket-socket-options

The availabilities took a bit more digging up but that was the basic idea.

I removed the " needs backport to 3.6" label, the 3.6 branch no longer accept bugfixes (only security fixes are accepted): https://devguide.python.org/#status-of-python-branches

At the very least, I think adding documentation for the list of options that socketmodule exports and getsockopt/setsockopt would be useful. I agree that the compatibility table is a bit of a pain to maintain.

I agree. In one hand I like the table (not having to search the info for an OS you don't know is nice), but it's probably too much work to maintain. Let's just start by documenting the exposed options. @ammaraskar can you remove the compatibility list and fix the previous reviews about?

@ammaraskar, please address the review comments.

This PR is stale because it has been open for 30 days with no activity.

Closing as it's been more than two years since changes were requested. Feel free to reopen or submit a new PR.