Author aeros
Recipients aeros, asvetlov, dacut, gvanrossum, ned.deily, njs, pitrou, vaizki, yselivanov
Date 2019-11-22.23:12:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1574464360.64.0.253167735664.issue37228@roundup.psfhosted.org>
In-reply-to
Content
> This was reported by a partner that was working porting our code to Android but might be fixed current Android API levels. I cannot test this myself.

Thanks, it's helpful to be aware of potential incompatibilities either way. I don't think we directly support or test Android, based on https://buildbot.python.org/all/#/builders. There's some degree of _indirect_ support because Android kernels are based on Linux LTS kernels, but there are substantial differences.

> Fully agree, part of the reason why I was suggesting getting rid of reuse_address and reuse_port completely on this higher level API. 

> But I'm happy with Antoine's proposal which effectively kills the reuse_address parameter, just suggesting we also kill reuse_port as well.

Removing support for the *reuse_address* parameter can be justified with the security issue, but I don't think we have significant justification to also remove *reuse_port* in the same PR. In general, removing a parameter is not something taken lightly because of the backwards compatibility concerns. 

I think the argument for eventually deprecating *reuse_port* on the basis of it directly mapping to a low-level OS API could be worth further discussion, but that's a topic for an entirely separate issue IMO. If it is approved, it would have to go through the usual deprecation process, likely starting in 3.9 with a DeprecationWarning and a removal no sooner than 3.11.
History
Date User Action Args
2019-11-22 23:12:40aerossetrecipients: + aeros, gvanrossum, pitrou, ned.deily, njs, asvetlov, yselivanov, dacut, vaizki
2019-11-22 23:12:40aerossetmessageid: <1574464360.64.0.253167735664.issue37228@roundup.psfhosted.org>
2019-11-22 23:12:40aeroslinkissue37228 messages
2019-11-22 23:12:39aeroscreate