> Deprecation means your code will still work I hope every book that > documents "except:" also adds "but don't use this except under very > special circumstances". > > I think you're overreacting (again), Raymond. 3.0 will be much more > successful if we can introduce many of its features into 2.x. Many of > those features are in fact improvements of the language even if they > break old code. We're trying to balance between breaking old code and > introducing new features; deprecation is the accepted way to do this.
IMO, the proponents of 2.x deprecation are underreacting. Deprecation has a cost -- there needs to be a corresponding payoff. Deprecation is warranted if the substitute code would still run on future Pythons (Michael explained the issues here). Deprecation is only warranted if the interim substitute works -- AFAICT, there is no other way to broadly catch exceptions not derived from Exception. The effort is only warranted if it makes the code better -- but here nothing is currently broken and the new code will be much less attractive and less readable (if the changes are done correctly); only 3.0 will offer the tools to do it readably and beautifully. Also, as we learned with apply(), even if ignored, the deprecation machinery has a tremendous runtime cost. None of this will make upgrading to Py2.5 an attractive option. There is a reason that over 120 bare except clauses remain in the standard library despite a number of attempts to get rid of them. It won't be trivial to properly evaluate whether each should be Exception or BaseException; to catch string exceptions; to write the test cases; to follow other PEPs requiring compatibility with older Pythons; or to do this in a way that it won't have to be done again for Py3.0. If the proponents don't have time to fix the standard library, how can they in good conscience mandate change for the rest of the world. Besides, I thought Guido was opposed to efforts to roam through mountains of code, making alterations in a non-holistic way. With a change this complex, the odds of introducing errors are very high. Fredrik, please speak up. Someone should represent the users here. I'm reached my limit on how much time I can devote to thinking out the implications of these proposals. Someone else needs to "overreact". _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
