[Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements
ncoghlan at gmail.com
Wed Mar 26 00:03:52 CET 2014
On 26 Mar 2014 08:35, "Antoine Pitrou" <solipsis at pitrou.net> wrote:
> On Tue, 25 Mar 2014 23:09:45 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
> > Alternative: selectively backport particular APIs
> > -------------------------------------------------
> > An instinctively minimalist reaction to this proposal is to only
> > particular APIs in the affected modules that are judged to be "security
> > critical". However, this ends up providing a worse end user experience,
> > as well as a worse developer experience.
> > For end users, the selective backporting approach means learning not
> > the legacy Python 2.7 API and the current Python 3 APIs, but also the
> > hybrid API created by the selective backporting process.
> I think this is a strawman, since you are also advocating for a
> "feature detection" approach to writing cross-version code. It is
> already required, actually, if wanting to write code compatible from
> 3.2 to 3.4 (for example, SSLContext exists in 3.2 but
> create_default_context appears in 3.4 while OP_NO_COMPRESSION appears
> in 3.3).
> I would much rather selectively backport a minimal set of APIs than the
> whole range of ssl APIs. There are things there (RAND_bytes,
> RAND_pseudo_bytes) that are not even useful for network security, or
> only in a rather uncommon manner (such as channel bindings).
Yeah, I think this is a valid point, and, as Guido noted, we also want the
option to skip backporting things if they depend on other aspects of Python
3 that we decide can't be backported.
So a feature-by-feature decision making process actually does make more
sense than a blanket exemption.
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev