Tres Seaver writes: > Re-adding features to make the strategy that works less painful is > just acknowledging that fact. Whether the strategy that works was anticipated is irrelevant, and the fact that pain *would* be involved was acknowledged all the way back to the days when "Python 3000" was still a python-dev in joke rather than something that downstream needed to think about for the future. The question is "how much pain", and I'm sorry, but I don't see that the .iterthingee methods involve so much pain. The request for explanation and quantification seems eminently reasonable to me. > Mark such features as BBB-only / deprecated-but-never-to-be-removed, and > move on: "practicality beats purity". Since your statement is a first-order sentence, it's implicitly universally quantified. "All" is a *lot* of cruft, Tres! Where do *you* propose finally saying "the cruft stops here"? Also, whatever cruft ends up being included *will* be propagated forward in code that does *not* need it, including new code. Most "new" code is plagiarized to some degree, and people plagiarize not with a critic's eye, but with an eye to "does the API have the semantics I need when it calls that code?" Nor do they enable deprecation notices, or read documentation if the reused code Just Works....
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