>> If the 3.0 API of a module is going to involve breakage which >> requires authors to update their applications wouldn't this be a good >> time to PEP-8-ify the module? (Not suggesting that threading would >> fall into this category.) Nick> Updating application code to deal with a module name change is Nick> easy - just use an "import x as y" statement. Catching the Nick> ImportError for the 3.0 name and falling back to the 2.6 name (or Nick> vice-versa) even makes it possible to support both names fairly Nick> easily. Nick> Changing the names of actual objects within the modules is tougher Nick> though - there are many more ways to access those.
I think you misunderstood what I wrote. Suppose you decided that the API for the threading modules needs significant rework, changes which will break much, if not all current usage. I'm only suggesting that if you decide the API change is worthwhile that you take the opportunity to make the class, method and data names PEP8-compliant. I'm not talking about gratuitous change to the identifier names, but situations where the user is going to have to rework their code anyway.