[Twisted-Python] Phasing out old-style classes

[Kelly]

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.
>
> Jean-Paul


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.

Presumably there will be a period when Twisted works on both 2.x and
3.x.  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.