IZIP PYTHON 2.7 SERIES
Series before 2.x moves into an extended maintenance period. The Python 2.7 series is scheduled to be the last major version in the 2.x SimpleXMLRPCServer denial of service), and issue 13885 (CVE-2011-3389,ĭisabling of the CBC IV attack countermeasure in the _ssl module). Reported security issues in 2.7.2: issue 13703 (oCERT-2011-003, hashĬollision denial of service), issue 14234 (CVE-2012-0876, hash tableĬollisions CPU usage DoS in the expat library), issue 14001 (CVE-2012-0845, Python 2.7.3 was released on April 9, 2012.
Its use is recommended over previous versions Since noone have spoken in favor of 2.7 backport, I am closing this issue as committed to p圓k.Note: A newer bugfix release, 2.7.4, is currently available. While there is no similar work-around for reduce, I don't think this bug is important enough to introduce backward incompatible change in the stable series.
IZIP PYTHON 2.7 CODE
Arguably, switching to izip and imap in new code is a good idea regardless of this issue.
IZIP PYTHON 2.7 ZIP
I also note that for zip and map, 2.7 users can switch to izip and imap which don't have this problem. While I agree that this is a bug, fixing it has a potential of breaking users' code. I am inclined to reject this for 2.7, however. Accepting this change for p圓k was an easy decision to make because zip and map already behave this way in 3.x. My reasoning is that out of the three functions, zip, reduce and map, zip is probably the most common and changing its behavior is more likely to affect somebody than a change to the other two.Īuthor: Alexander Belopolsky (belopolsky) *Ĭommitted to p圓k in r84098. I my view this slightly preferable to the "all the way" approach of letting all exceptions to propagate up.
IZIP PYTHON 2.7 PATCH
I am attaching a patch with unit tests that implements the "middle-ground approach" making map and reduce behave the way zip is now. The patch looks OK, but I think it should be reworked to take the middle-ground approach, replacing only TypeErrors.Īuthor: Alexander Belopolsky (Alexander.Belopolsky)
Walter's comment at 06:29 shows this can still be fooled, but a fix for 90% of the cases is still better than a fix for 0% of them. Preserving the argument number seems difficult without exception chaining perhaps a middle group would be to only replace TypeError exceptions. The cleanest solution would really be exception chaining. Here the open call will raise a TypeError, that is totally Through things like the IOError in your original example. Style in zip() which only traps TypeErrors but passes One way to mitigate the information loss is to mimic the Unfortunately this loses the information about whichĪrgument triggered the exception (in map() and zip()) I recommend fixing them all.Īttached is a patch that fixes reduce(), map() and zip(). Not iteratable, the original exception is just as good: Original exception "IOError: No such file orĭirectory: 'does not exist'" and when the second argument is Support iteration") in builtin_reduce(), will produce the Removing theĬall PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must Problem of the non existing file is masked. LazyFile *does* support iteration, but the underlying Masks the error returned from PyObject_GetIter(). The point is that Python/bltinmodule.c/builtin_reduce() So I believe theĮrror message is correct - Test does not support iteration. The _iter_ method is supposed to return an object thatĭefines a 'next' method. PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must TypeError: reduce() arg 2 must support iteration The real IOError exception is masked, i.e. Ajaksu2, akuchling, belopolsky, doerwalter, rhettinger, vstinnerĬreated on 14:41 by doerwalter, last changed 16:06 by admin.
0 kommentar(er)
