<div dir="ltr"><div><div><div><div><div>Hi!<br><br></div><div>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 :)<br>

<br></div><div>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 :)<br>

</div><div><br></div><div>Benefits:<br><br></div><div>- We get to use everything that requires new-style classes, e.g. the descriptor protocol, and by extension classmethods, staticmethods, properties...<br></div><div>- Performance benefit on PyPy<br>

</div><div>- Consistency of behavior between 2.x and 3.x<br></div><div><br></div>Counterarguments:<br><br></div>- 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.<br>

</div>- 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).<br>

<br></div>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 :)<br>

<br>For new development, IIUC, new-style classes are already a requirement, so this doesn't affect it.<br><br></div>cheers<br>lvh<br></div>