[Twisted-Python] Twisted and new-style classes

[Laurens Van Houtven]

Hi!

Maciej from the PyPy team has graciously offered to upgrade all of
Twisted's existing old-style classes to new-style. The reason this is now
also a mailing list thread is because it may, potentially, break some
things, and we want people to have a heads up. Of course, Twisted will
never break your stuff without warning (at least not intentionally) and the
normal compatibility policy is in effect as always :)

The catch is that Maciej wants some kind of guarantee that at some point,
this will be on by default. At least two committers (myself and Glyph) want
this, so I'm confident this is the case: unless someone highlights a huge
flaw in my reasoning that shows that we can't actually do this :)

Benefits:

- We get to use everything that requires new-style classes, e.g. the
descriptor protocol, and by extension classmethods, staticmethods,
properties...
- Performance benefit on PyPy
- Consistency of behavior between 2.x and 3.x

Counterarguments:

- It's a lot of work. That's true, but shouldn't concern you: we have
someone who says they're willing to actually do that work.
- It will break things. That is probably true, but Twisted never promises
not to break anything ever. It has a compatibility policy, the guiding line
for which is "the first one is always free". As long as we have a full,
real release where we *warn* people that something is going to happen and
they should test it now, we're satisfying that policy. The problem is that
AFAICT there's no obvious way to identify where problems will occur (since
it's a consequence of how people use current old-style things). The
suggested approach to this is that we have a release where all classes that
are going to be new-style are old-style by default, but, given e.g. an
environment variable, all of them *can* be new-style. The warning could
then be that you should turn on that environment variable (requiring
conscious action and being easy enough to undo if your code breaks).

I would suggest doing the transition in small steps, and adding the
environment variable as a priority. That way, people who know about this
can at least already run their tests before the entire process is complete.
Also, just because it has to be complete (but off by default) for at least
one release, doesn't mean it has be exactly one release :)

For new development, IIUC, new-style classes are already a requirement, so
this doesn't affect it.

cheers
lvh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://twistedmatrix.com/pipermail/twisted-python/attachments/20130715/2eb009ca/attachment.html>