On Sun, Oct 25, 2009 at 1:50 AM, <exarkun@twistedmatrix.com> wrote:
On 02:39 pm, k.kelly.gordon@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.