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.... _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
