[Twisted-Python] Phasing out old-style classes

exarkun at twistedmatrix.com exarkun at twistedmatrix.com
Tue Oct 27 08:17:02 EDT 2009

On 08:38 am, k.kelly.gordon at gmail.com wrote:
>On Sun, Oct 25, 2009 at 1:50 AM,  <exarkun at twistedmatrix.com> wrote:
>>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:
>>>>If old-style classes can be evolved into new-style classes while
>>>>somehow following this policy, that would be great.
>>>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.
>>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 guess that would be a problem if an application used two libraries
>that use Twisted and each initialised Twisted differently.  However, I
>was thinking this would be something that should only be called by
>the application (ie the thing with #! at the top)
>Roughly speaking - in the Twisted library:
>    from twisted.object import ClassStyle
>    class MustBeOldStyle(ClassStyle.old): pass
>    class DoesntMatter(ClassStyle.default): pass
>In the application's top level file:
>    #!/usr/bin/env python
>    from twisted.object import ClassStyle
>    ClassStyle.use_old_style()
>    # or
>    ClassStyle.use_new_style()
>Which would have the effect flipping ClassStyle.default between old
>and new style.  Once set it can't be changed which is why it needs to
>be done before any Twisted classes are defined.
>>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.
>How could that be done in a way that was consistent with the
>deprecation policy?  ie how could a warning be issued: "this class
>will be new style in a couple of releases", such that the developer
>could "fix" their code to remove the warning?
>Changing from old-style to new-style changes a number of class
>behaviours (notably: mro, __coerce__, assignment to Class.__dict__
>and Class.__bases__), so its not really something that can be done
>silently to any class that might be inherited from.

Actually, I was thinking that we would only do it to classes that can 
not be inherited from.  For example, no one's really supposed to be 
subclassing Deferred, so we might consider making Deferred new-style 
(perhaps for performance reasons, for example).
>Presumably there will be a period when Twisted works on both 2.x and

I think it is still early to presume this. :)
>At that point there will be two sets of users,  the 3.x's that
>use only new-style classes and the 2.x's for which Twisted classes
>may be either old or new.  It would probably be better to have
>switched to new-style before then and only have to support the use
>of new style classes.

But, presuming this :) I don't think we need to have switched to new- 
style classes for support this scenario.  We only have to have written 
all our code such that it continues to work even when there are no 
longer any classic classes.  I think that the majority of code in 
Twisted already works even if you flip the new-style switch.  We just 
need to identify and fix the few places that don't.
>Twisted-Python mailing list
>Twisted-Python at twistedmatrix.com

More information about the Twisted-Python mailing list