On Mon, 2006-03-27 at 23:53 -0800, Raymond Hettinger wrote: > While I don't favor the proposed API, I think is essential that > you not be left hanging without good options. Thank you. So where does this leave us? BTW, Guido made a suggestion in private email (which he okayed to mention publicly). Quoting: "OTOH, our experience with dicts have shown that the C dict API causes major constraints on dict subclassing (since the C APIs mostly ignore overridden methods) and the proliferation of their use makes it hard to implement features like allowing arbitrary mappings as globals/locals for exec/eval." "Perhaps the PySet API can raise an error if it's ever called on something that's not *exactly* a set? No subclassing allowed. Shouldn't affect you, and should be an effective deterrent against abuse of the kind that made the PyDict API an albatross." This would involve changing the type test in PySet_Next() from a PyAnySet_Check() to a PyAnySet_CheckExact() so that it only works for sets and frozen sets. Guido's exactly right, it wouldn't affect us so it seems like it would be fine. I'm not sure if this directly addresses your concerns though, since they seem mostly centered around the safety (or lack thereof) of PySet_Next(). -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/20060328/58162fd1/attachment-0001.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