Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #81039

Re: Potential pitfalls when going from old-style to new-style classes

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

On Wed, Nov 19, 2014 at 11:14 AM, Skip Montanaro <skip.montanaro@gmail.com>
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.

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: Potential pitfalls when going from old-style to new-style classes Chris Kaynor <ckaynor@zindagigames.com> - 2014-11-19 11:34 -0800

csiph-web