[Twisted-Python] incompatible change in 15.3 - something reviewers should look for
In https://twistedmatrix.com/trac/changeset/45163 twisted.internet.application.service.Service to be a new-style class. Just to remind everyone, converting an old-style class to a new-style class is an incompatible change, and reviewers should look for this. We discovered this because this change breaks https://github.com/twisted/axiom, and probably it breaks other packages as well, since lots of things inherit from Service. So please remain diligent about looking for this in future changes. Now that it's been changed, reverting it in 15.4 would be another incompatible change, so we probably won't do that, but please keep an eye out in the future. -glyph
Hi, Thanks for the notice! On 12 August 2015 at 01:24, Glyph <glyph@twistedmatrix.com> wrote:
In https://twistedmatrix.com/trac/changeset/45163 twisted.internet.application.service.Service to be a new-style class. Just to remind everyone, converting an old-style class to a new-style class is an incompatible change, and reviewers should look for this.
I have updated the wiki page to include this note and the reason why we need this. https://twistedmatrix.com/trac/wiki/Plan/Python3#Reviewerchecklist Please check that wiki page is ok. In my defense :) Amber warned me about such changes, but when I asked (over IRC) why they are bad I did received any convincing reason :)
We discovered this because this change breaks https://github.com/twisted/axiom, and probably it breaks other packages as well, since lots of things inherit from Service. So please remain diligent about looking for this in future changes. Now that it's been changed, reverting it in 15.4 would be another incompatible change, so we probably won't do that, but please keep an eye out in the future.
I assume that this is the error in axiom: https://github.com/twisted/axiom/issues/44 In axiom a class was defined as class _SiteScheduler(object, Service, SchedulerMixin) Is this a common practice? Why do you want to have multiple inheritance and put object as the first inherited class and not the last one? Regards, -- Adi Roiban
On Wed, 12 Aug 2015 at 07:25 Adi Roiban <adi@roiban.ro> wrote:
On 12 August 2015 at 01:24, Glyph <glyph@twistedmatrix.com> wrote:
We discovered this because this change breaks https://github.com/twisted/axiom, and probably it breaks other packages as well, since lots of things inherit from Service. So please remain diligent about looking for this in future changes. Now that it's been changed, reverting it in 15.4 would be another incompatible change, so we probably won't do that, but please keep an eye out in the future.
I assume that this is the error in axiom: https://github.com/twisted/axiom/issues/44
In axiom a class was defined as
class _SiteScheduler(object, Service, SchedulerMixin)
Is this a common practice? Why do you want to have multiple inheritance and put object as the first inherited class and not the last one?
From the perspective of Twisted development, why does it matter?
Changing a class from old style to new style changes the method resolution order, which is going to break lots of code in ways that we can't anticipate. We can't find every subclass and judge whether their usage makes sense. We can only stick to our compatibility policy <https://twistedmatrix.com/trac/wiki/CompatibilityPolicy>, which empowers users to decide when & how they change their weird code. jml
On Aug 12, 2015, at 3:46 AM, Jonathan Lange <jml@mumak.net> wrote:
From the perspective of Twisted development, why does it matter?
The one reason that it matters is that we need to consistently tell users how to prepare for the fact that eventually, everything will be new-style. Perhaps it will only be new-style because we eventually drop python 2, perhaps it will only be new-style because python 2.8 will deprecate classic classes, perhaps we will eventually have a flag day just to reduce the maintenance burden, perhaps each old-style class will be individually deprecated and replaced with a new-style one. In any case, the migration will be much easier for users if they learn now that putting 'object' at the end of their bases list is a way to avoid caring about this issue entirely :). Otherwise I agree completely with your sentiment. -glyph
participants (4)
-
Adi Roiban -
Glyph -
Glyph Lefkowitz
-
Jonathan Lange