[Twisted-Python] Phasing out old-style classes

exarkun at twistedmatrix.com exarkun at twistedmatrix.com
Sat Oct 24 10:50:11 EDT 2009

On 02:39 pm, k.kelly.gordon at gmail.com wrote:
>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> 
>> > I've been bitten a couple times by twisted's use of old-style 
>> > Now that Jython is finally off the 2.2 branch, is there any real 
>> > 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 
>>from it, changing the class to be new-style can have effects from 
>>how their descriptors work to causing an exception when their module 
>>If old-style classes can be evolved into new-style classes while 
>>following this policy, that would be great.  The problem is that 
>>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 
>>and "NewFoo" or "Foo2" sitting right next to it, so we would have to 
>>of new names for everything.
>I have some POC code for this.  It provides a simple toggle at the 
>of the application to select between old style (the default) and new 
>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?

Process-wide switches are tricky.  Some code may decide it wants new- 
style, while other code wants to stick with classic.  They have a fight, 
one of them loses.  I think that adding this is just an invitation for 
people to create more problems.

I think that we should consider requests to make specific classes new- 
style (and grant them when doing so won't cause compatibility problems), 
make all new classes new-style, but otherwise leave this alone until 3.x 
is widely adopted.


More information about the Twisted-Python mailing list