On Thu, Jun 12, 2008 at 11:32 PM, Georg Brandl wrote:

Guido van Rossum schrieb:

...

It's water under the bridge now, but IMO it was too rash to *remove* the old threading API from Py3k, and doubly rash to do so one day before the beta release. Running up to a release (whether alpha, beta or final) we should practice extra restraint, not rush to get things in right before the deadline. Let's all be more careful the rest of this release cycle! (I think it wasn't just Benjamin who raced to get things in...)

Also, for any method or module renaming, there is no way around a full grep through the code base to really catch all uses of the old API.

Eh? Even a full grep won't reveal 3rd party uses of the old API. While 3.x is intentionally breaking some things, this is not (and was never meant to be) as a blanket approval to break any API we feel like breaking. Each specific breakage must have a good motivation, e.g. the old API is confusing, or inefficient, or disallows certain uses -- non-PEP-8-conformance alone is not enough! In addition, each specific breakage must be weighed against the cost of updating 3rd party code, and whether a good (or at least fair) automatic conversion can be added to 2to3.

It may be tedious, especially with common names, but such bugs really must be avoided as they can easily be -- I still could find uses of old-style threading names, even in the stdlib. (Fixed in r64222.)

All the more reason not to rush into API renamings without due process and lots of discussion. Let's err on the side of the status quo -- otherwise we'll never be ready for beta. -- --Guido van Rossum (home page: http://www.python.org/~guido/)