On Mar 25, 2014, at 12:35 PM, Guido van Rossum <gu...@python.org> wrote:
> On Tue, Mar 25, 2014 at 8:31 AM, Alex Gaynor <alex.gay...@gmail.com> wrote: > A casual glance at > https://github.com/kennethreitz/requests/blob/master/requests/packages/urllib3/ > util.py#L610 > which is probably the most widely used consumer of these APIs, outside the > stdlib itself, looks to me like if these names were to suddenly show up, > everything would continue to work just fine, with the advance of being able to > explicitly specify some options. > > All of which is to say: I don't think this is a real concern. > > That would be great, because I have no other major beef with the PEP (but I > still need to read in in full -- it's long and half of it still feels like > weasel words to me, so I can't apply my usual skimming tactics). > > I would like the PEP (or perhaps a companion PEP?) spell out the set of > enhancements that we would *currently* like to see backported from Python 3.4 > to 2.7, without the implication that these would be the *only* enhancements > -- such a list would serve as an example and to focus the understanding. The > PEP currently doesn't even name SSLContext! > > I wouldn't be totally surprised to find that there are some details of some > API added to Python 3.4 that simply cannot be backported due to some > important difference between Python 2 and 3 (e.g. because of differences in > Unicode handling, or a missing socket method). I don't think such things > would be showstoppers, they would just have to be worked around carefully; > but it would be better to know about them now rather than having to figure > out how to comply with the PEP's insistence of a full backport. > > I do note that the PEP seems to have some weasel-words about breaking > backward compatibility in the name of security. The phrase "This PEP does not > grant Python 2.7 any general exemptions to the usual backwards compatibility > policy for maintenance releases" *could* be interpreted to imply that the PEP > grants some specific exemptions (regardless of whether that was Nick's > intention when he wrote that sentence). I'd like clarity on this; IIRC we've > had to make some compatibility-breaking changes in the past for security > reasons, but I don't recall the details or how that worked out (whether much > code broke and whether that was considered a good or a bad thing). I’m pretty sure Nick was just trying to say that the changes made under this PEP still have to be backwards compatible in the sense that APIs can’t change their default behavior and such. In other words we can’t suddenly flip on hostname checking or anything like that. > > -- > --Guido van Rossum (python.org/~guido) > _______________________________________________ > 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/donald%40stufft.io ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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/archive%40mail-archive.com
