Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.albasani.net!news.stack.nl!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.003 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'classes,': 0.05; 'pop': 0.05; 'python)': 0.05; 'suppose': 0.07; 'classes.': 0.09; 'def': 0.12; 'mostly': 0.14; 'question.': 0.14; '__slots__': 0.16; 'inheritance': 0.16; 'magic': 0.16; 'new-style': 0.16; 'old- style': 0.16; 'overriding': 0.16; 'received:74.125.82.46': 0.16; 'subclassing': 0.16; 'subject:when': 0.16; 'wrote:': 0.18; 'discussion': 0.18; 'wed,': 0.18; 'bit': 0.19; '(the': 0.22; '2.x': 0.24; "shouldn't": 0.24; 'skip': 0.24; 'looks': 0.24; 'defined': 0.27; 'header:In-Reply-To:1': 0.27; 'am,': 0.29; 'properties': 0.29; 'errors': 0.30; 'message-id:@mail.gmail.com': 0.30; 'code': 0.31; 'object.': 0.31; 'trivial': 0.31; 'class': 0.32; 'run': 0.32; 'skip:_ 10': 0.34; 'received:74.125.82': 0.34; 'subject:from': 0.34; 'could': 0.34; 'problem': 0.35; 'common': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'accessing': 0.36; 'object,': 0.36; 'changing': 0.37; 'example,': 0.37; 'list': 0.37; 'being': 0.38; 'subject:new': 0.38; 'nov': 0.38; 'to:addr:python-list': 0.38; 'received:74.125': 0.39; 'to:addr:python.org': 0.39; 'anytime': 0.60; 'most': 0.60; 'reserved': 0.61; 'new': 0.61; 'more': 0.64; 'obvious': 0.74; 'behavior': 0.77; 'subject:Potential': 0.91; 'serious': 0.97 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=KUf1aCybf2v5SAFEA5gH7MbCT+H3AgdwP30bgDvyAj4=; b=LYvHz4fZ8MhSpGwlv8aKGdkpk4XDgHZUUXC04AT04h6XFkmutilLzQtKHUOTyMkUWO wgZL7qflFShHcAWIBujNBVrJZk1DPAy7IgwmzZrXVHpv2cVNRfKcIPntQQTdUdFYyUHS g0/s2vsk1wnRMroDzq4+Qeccl7hPvVJ40110ArG7uHD/EXIVide24zy1Vo4l+e2dqa5l SoP/ozmXm8evt31+Ch7akB5u8CB987mg8JRxILE92FrRzY9Xq4sItnLy6RnQY98LmJkl NnNDS/+wJEK4qx8ZflVOcdyRYG6PIjros2doj6RwoOX6aXE8or+qKiTfKbS4LjzYdwo9 KJGA== X-Gm-Message-State: ALoCoQnHlZpEokuwLzsZvuaQ7ejTq8dvsR2LQHy2s9pFzxg18Uc+Iqz7H0t50MfdO4s7lSC6vHYg X-Received: by 10.180.187.67 with SMTP id fq3mr15997081wic.37.1416425705143; Wed, 19 Nov 2014 11:35:05 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: From: Chris Kaynor Date: Wed, 19 Nov 2014 11:34:44 -0800 Subject: Re: Potential pitfalls when going from old-style to new-style classes To: Python Content-Type: multipart/alternative; boundary=001a11c3807001981005083b4f91 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 78 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1416425714 news.xs4all.nl 2874 [2001:888:2000:d::a6]:49679 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:81039 --001a11c3807001981005083b4f91 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 19, 2014 at 11:14 AM, Skip Montanaro wrote: > I discussion on the code-quality list got me thinking. Suppose I have > an old-style class in a 2.x app: > > class Foo: > def __init__(self): > blah blah blah > > I still use 2.x exclusively, but anytime I run pylint over a bit of > code and it complains that Foo is old-school, I make the obvious > change to inherit from object. While I do this mostly to shut up > pylint so I can focus on more serious messages, I must admit I have > never experienced any problem changing from old-style to new-style > classes. Under what circumstances might this be problematic? > Under most common cases, its as trivial as just subclassing object, however there are some oddities: - The main case errors may pop up is with multiple inheritance (MRO was changed). - If you are accessing or have defined magic methods. - For example, overriding __call__ on a specific instance will no work with new-style classes, but will work with old-style classes. Defining it on the class (the common case) works the same in both cases. - A number of new magic properties were added, __slots__ and __mro__. So if those are being defined (they shouldn't - all dunder names are reserved by Python) it could change behavior oddly. It looks like http://stackoverflow.com/questions/54867/old-style-and-new-style-classes-in-python has some decent answers to your question. --001a11c3807001981005083b4f91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 19, 2014 at 11:14 AM, Skip Montanaro <skip.montanaro@gmail= .com> wrote:
I discussion on the code-qua= lity list got me thinking. Suppose I have
an old-style class in a 2.x app:

class Foo:
=C2=A0 def __init__(self):
=C2=A0 =C2=A0 blah blah blah

I still use 2.x exclusively, but anytime I run pylint over a bit of
code and it complains that Foo is old-school, I make the obvious
change to inherit from object. While I do this mostly to shut up
pylint so I can focus on more serious messages, I must admit I have
never experienced any problem changing from old-style to new-style
classes. Under what circumstances might this be problematic?

Under most common cases, its as trivial as just subcl= assing object, however there are some oddities:
  • The main = case errors may pop up is with multiple inheritance (MRO was changed).
    • =
  • If you are accessing or have defined magic methods.
    • For exa= mple, overriding __call__ on a specific instance will no work with new-styl= e classes, but will work with old-style classes. Defining it on the class (= the common case) works the same in both cases.
    • A number of new magi= c properties were added, __slots__ and __mro__. So if those are being defin= ed (they shouldn't - all dunder names are reserved by Python) it could = change behavior oddly.
It looks like=C2=A0http://stackoverflow.com/questions/54867/old-style-and-new-style-clas= ses-in-python has some decent answers to your question.
--001a11c3807001981005083b4f91--