add an automated test which will fail if any old-style classes (AKA classic classes) are added

[glyph]

We have some classic classes in Twisted, but we don't want to add any more. (Citation needed: where's our policy document that says no classic classes? I can't find it.) Python 3 is new-style only and it would be nice if we only had one kind of object model; however, application code may well be relying upon the classic-class behavior of its inherited classes and fail in an ugly way ("Cannot create a consistent method resolution order" being the most popular one).

This is an easy thing to miss in a review; it's just the absence of the word "object". It could easily be enforced automatically, and it should be.

(This would be part of the trial test suite but it's not a "unit test" really, so let's not call it that.)

[ashfall]

Indeed, it would be nice if trial had this: exarkun pointed it out in point 2 of this review comment (the branch still lacks the said test, though). Not sure if twisted.internet.test.test_core.ObjectModelIntegrationMixin.assertFullyNewStyle is a good reference for this automatic enforcement, but an example test, nevertheless.

[exarkun]

Note that this ticket isn't quite about the same thing as assertFullyNewStyle.

For a class to be new-style, object needs to appear in (at least) one place in its inheritance hierarchy. assertFullyNewStyle is for verifying that every base class in the inheritance hierarchy is new-style. This is only sometimes possible (for example, protocols are almost all classic, so no subclass (and subclassing is a big part of how protocols are used) can be fully new-style).

Apart from that, in order to verify that no new classic classes are added, we need a list of classic classes that are being grandfathered in. This makes me feel like a ratchet-style buildbot-based checker, similar to the pyflakes or pydoctor builders, would be well better suited to the problem. This avoids the need to build a big list of classic classes and dump it into a test in Twisted somewhere.

However, I guess either approach will work. I'm just a bit uneasy about this kind of whole-codebase "unit" test - and even if we don't call it a unit test, unit testing is what trial is for and what it is good at.