Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #81038 > unrolled thread
| Started by | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| First post | 2014-11-19 11:29 -0800 |
| Last post | 2014-11-19 11:29 -0800 |
| Articles | 1 — 1 participant |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Potential pitfalls when going from old-style to new-style classes Ethan Furman <ethan@stoneleaf.us> - 2014-11-19 11:29 -0800
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2014-11-19 11:29 -0800 |
| Subject | Re: Potential pitfalls when going from old-style to new-style classes |
| Message-ID | <mailman.15998.1416425382.18130.python-list@python.org> |
[Multipart message — attachments visible in raw view] — view raw
On 11/19/2014 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?
One problem is if your class has dunder methods on the instance -- they will be ignored.
class Foo(object):
def __init__(self):
self.__add__ = lambda : 'whatever'
dunder methods are looked up on the class.
--
~Ethan~
Back to top | Article view | comp.lang.python
csiph-web