[Twisted-Python] Phasing out old-style classes
k.kelly.gordon at gmail.com
Sat Oct 24 10:39:40 EDT 2009
On Thu Oct 8 20:08:12 EDT 2009, Glyph Lefkowitz <glyph at
> 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
> 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?
More information about the Twisted-Python