[Anders J. Munch] >> There is a simpler way to make sure all clients that illicitly use >> ob_item are updated appropriately: Break the build by renaming. If >> ob_item is renamed to ob_items or ob_item2 or whatever, any code that >> uses the old name will cease to compile. [Guido] > Good idea. We'd also have to break binary compatibility (of the List > API) forcibly otherwise we could be fooled by 3rd party extensions > compiled for older Python versions -- usually we're careful to keep > binary compatibility. I think it's a bad idea, at least until Raymond produces evidence that overwriting ob_item in extensions isn't "just a myth". Not even Zope's C code does that (which is my poster child for pushing the line on Python's internals). Google doesn't turn up few enough hits on ob_item to study exhaustively, and there's no hint via doing so that any code indexed by Google has mucked with ob_item either.
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