[Twisted-Python] Phasing out old-style classes

[Kelly]

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?