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? _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
