This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vaizki
Recipients aeros, asvetlov, dacut, gvanrossum, ned.deily, njs, pitrou, vaizki, yselivanov
Date 2019-11-21.15:33:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
>  A higher-level interface like asyncio doesn't necessarily want to map its kwargs directly to non-portable low-level options like this.

Also reuse_port has portability issues, the whole portability mess i s nicely summed up in:

And the docs say that "If the SO_REUSEPORT constant is not defined then this capability is unsupported." which is true but the converse is not - some platforms apparently do have SO_REUSEPORT defined but the option still doesn't work, resulting in a ValueError exception from create_datagram_endpoint().

So to create truly portable code, the developer who really wants to use these options has to know differences between underlying OS and kernel versions, catch errors that shouldn't happen according to docs and then try again with different options. 

This is ok for lower level APIs like socket.socket where things map 1:1 to system calls but not a good thing on higher level APIs as you point out. In my C++ projects that use these, I just have a #ifdef block for every OS and don't even try to abstract it.
Date User Action Args
2019-11-21 15:33:05vaizkisetrecipients: + vaizki, gvanrossum, pitrou, ned.deily, njs, asvetlov, yselivanov, dacut, aeros
2019-11-21 15:33:05vaizkisetmessageid: <>
2019-11-21 15:33:05vaizkilinkissue37228 messages
2019-11-21 15:33:04vaizkicreate