On Sun, 2006-03-26 at 11:43 -0500, Raymond Hettinger wrote: > It was a trick question. Everyone is supposed to be attracted to the _next > version because it is shorter, faster, and takes less ref counting management. > However, the _next version has a hard-to-find bug. The call to PyObject_Hash() > can trigger arbitrary Python code and possibly mutate the table, leaving > pointers to invalid memory addresses. It would likely take Armin less than five > minutes to write a pure Python crasher for the code. And THAT is why > PySet_Next() should never come into being. We're clearly going in circles here, and it's obvious we're not going to agree. The fact that PySet_Next() can be used incorrectly is no reason not to include it. There are /lots/ of things in Python that if you use incorrectly will screw you. So you document them, teach people when not to use them, and teach them how to use them correctly when they /are/ the right thing to use. I don't want to be babied into using inappropriate and cumbersome APIs which, yes, can be a source of their own subtle bugs. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/python-dev/attachments/20060327/199640a0/attachment.pgp
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