Nick Coghlan added the comment: Test suites enable deprecation warnings by default, and many projects have a "no warnings allowed" rule. By adding programmatic deprecation warnings for the old APIs where there's no other way to it in a 3.3 compatible way, we make things more difficult for people that still need to support 3.3. I'm OK with doing that when there's a concrete payoff in significantly reducing our maintenance burden, eliminating an attractive nuisance (I took that as far as removing contextlib.nested entirely before coming up with ExitStack as a replacement), or when there's a concrete benefit to the *user* in migrating, but otherwise lean towards the "I want major Python upgrades to be exciting, not annoying" school of thought most of the time.
And yes, I'm biased through working on package stuff - all of that needs to straddle 2.6+ and 3.2+ due to platform support requirements, and I want people to be free to work on metadata 2.0 rather than figuring out how to avoid new deprecation warnings :) Your updated list of suggested near-term deprecations sounds a lot more reasonable to me - that stuff is all 3.3 specific, and the packaging ecosystem hasn't really adjusted to those yet anyway (given the heavy 2.6+ and 3.2+ bias). It was mostly the method deprecations that bothered me, since providing the "lowest common denominator" APIs is the easiest way to implement cross version compatible finders and loaders. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19713> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
