On Thu Oct 8 20:08:12 EDT 2009, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
On Thu, Oct 8, 2009 at 7:59 PM, Mark Visser <markv at lumierevfx.com> wrote:
I've been bitten a couple times by twisted's use of old-style classes. Now that Jython is finally off the 2.2 branch, is there any real reason to stay backwards compatible?
Changing a class from old-style to new-style is an incompatible change. The difficulty is that if existing libraries use a particular class and inherit from it, changing the class to be new-style can have effects from changing how their descriptors work to causing an exception when their module is imported.
...
If old-style classes can be evolved into new-style classes while somehow following this policy, that would be great. The problem is that providing compatibility at this level is time-consuming and difficult. One problem in particular is that we don't want to litter the codebase with lots of "Foo" and "NewFoo" or "Foo2" sitting right next to it, so we would have to think of new names for everything.
I have some POC code for this. It provides a simple toggle at the start of the application to select between old style (the default) and new style classes. After that, a DeprecationWarning is issued every time an old style class is defined. The only user visible change is that old style classes gain an empty old-style base class. The idea being the old-style/new-style migration could be managed using the usual twisted deprecation plan. Thoughts?