> > 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). Let's hear from Raymond about the use case. --Guido van Rossum (home page: http://www.python.org/~guido/)
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