"Guido van Rossum" <guido at python.org> wrote in message news:200402101540.i1AFeSR31177 at c-24-5-183-134.client.comcast.net... > Disagree. The public API documentation has never permitted modifying > ob_item and ob_size directly. It would be breaking the abstraction. That answers my previous question. > If in 3rd party code, that code is simply wrong. > > If indeed such 3rd party code exists, and we expect we can't get it > all fixed before 2.4 is released, the tracked_item hack can be used as > a temporary measure to hunt down all those 3rd party extensions that > break the abstraction. I propose to issue a warning when it is > discovered that ob_item != tracked_item. Then in 2.5 we can remove > the tracked_item feature. Why not publish warning/announcement now (clp, clpa, and site), put warning code in alpha/beta and possibly c1, and remove in c2 and 2.4 final? You regularly make changes at or visible from the Python level with less accomodation than this. (Examples: byte code changes; deletion of methods() and members() methods in favor of uniform dir() in 2.2). Terry J. Reedy
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