On Sun, Oct 25, 2009 at 4:38 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Oct 24, 2009, at 10:50 AM, exarkun@twistedmatrix.com wrote:
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.
While your argument makes sense to me, there's a fundamental problem with the way Python introduced new-style classes that creates an ongoing maintenance tension. I think we should start addressing the problem incrementally now (especially since it sounded like Kelly was volunteering for some work!) rather than put it off for one big chunk when we do a 3k migration.
Well yes I am. I am hoping that the discussion will get to a point where I understand what an acceptable solution might be, even if that should be like exarkun said "leave it alone/migrate classes one at a time".
I would really like a more abstract declaration that applications can use in the meanwhile, to get new-style semantics but still allow inheritable classes to evolve.
As noted by James, users of the Twisted library can add object to the end of their inheritance chain to get new style semantics for their classes. I was thinking more along the lines of being able to use new-style stuff inside the Twisted library.