On 26 Mar 2014 08:35, "Antoine Pitrou"
On Tue, 25 Mar 2014 23:09:45 +1000 Nick Coghlan
wrote: Alternative: selectively backport particular APIs -------------------------------------------------
An instinctively minimalist reaction to this proposal is to only
backport
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 only 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. Cheers, Nick.
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com