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 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). Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4