Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <51943f13$0$29997$c3e8da3$5496439d@news.astraweb.com>
References: <f4ce525a-2728-4ad6-9858-e9005534ee54@bz1g2000vbb.googlegroups.com> <mailman.1695.1368620192.3114.python-list@python.org> <51943f13$0$29997$c3e8da3$5496439d@news.astraweb.com>
From: Oscar Benjamin <oscar.j.benjamin@gmail.com>
Date: Thu, 16 May 2013 11:31:08 +0100
Subject: Re: Python 2.7.x - problem with obejct.__init__() not accepting *args and **kwargs
To: "Steven D'Aprano" <steve+comp.lang.python@pearwood.info>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Python List <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1748.1368700291.3114.python-list@python.org>
Lines: 93
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:45418

On 16 May 2013 03:06, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Wed, 15 May 2013 13:16:09 +0100, Oscar Benjamin wrote:
>
>
>> I don't generally use super()
>
> Then you should, especially in Python 3.
>
> If you're not using super in single-inheritance classes, then you're
> merely making your own code harder to read and write, and unnecessarily
> difficult for others to use with multiple-inheritance.
>
> If you're not using super in multiple-inheritance[1] classes, then your
> code is probably buggy.
>
> There really is no good reason to avoid super in Python 3.

I should have been clearer. I don't generally use super() because I
don't generally use Python in a very object-oriented way. My comment
was intended as a qualification of my advice rather than a suggestion
that there is something wrong with super(). I can certainly see how
that would be misinterpreted given the article I linked to:

>> but I did see some advice about it in this article:
>> https://fuhm.net/super-harmful/
>
> It's not a good article. The article started off claiming that super was
> harmful, hence the URL. He's had to back-pedal, and *hard*. The problem
> isn't that super is harmful, it is that the problem being solved --
> generalized multiple inheritance -- is inherently a fiendishly difficult
> problem to solve. Using super and cooperative multiple inheritance makes
> it a merely difficult but tractable problem.
>
> The above article is useful to see the sorts of issues that can come up
> in multiple inheritance, and perhaps as an argument for avoiding MI
> (except in the tamed versions provided by mixins or straits). But as an
> argument against super? No.

I read that article when I was trying to do something with multiple
inheritance. It was helpful to me at that time as it explained why
whatever I was trying to do (I don't remember) was never really going
to work.

>
> A much better article about super is:
>
> http://rhettinger.wordpress.com/2011/05/26/super-considered-super/

This is a good article and I read it after Ian posted it.

>
>
>> From the conclusion:
>> "Never use positional arguments in __init__ or __new__. Always use
>> keyword args, and always call them as keywords, and always pass all
>> keywords on to super."
>
> Even that advice is wrong. See Super Considered Super above.

Raymond's two suggestions for signature are:
'''
One approach is to stick with a fixed signature using positional
arguments. This works well with methods like __setitem__ which have a
fixed signature of two arguments, a key and a value. This technique is
shown in the LoggingDict example where __setitem__ has the same
signature in both LoggingDict and dict.

A more flexible approach is to have every method in the ancestor tree
cooperatively designed to accept keyword arguments and a
keyword-arguments dictionary, to remove any arguments that it needs,
and to forward the remaining arguments using **kwds, eventually
leaving the dictionary empty for the final call in the chain.
'''

The first cannot be used with object.__init__ and the second is not
what the OP wants. I think from the article that the appropriate
suggestion is to do precisely what the OP has done and make everything
a subclass of a root class that has the appropriate signature. Perhaps
instead of calling it my_object it could have a meaningful name
related to what the subclasses are actually for and then it wouldn't
seem so much like a dirty trick.

> [1] To be precise: one can write mixin classes without super, and
> strictly speaking mixins are a form of multiple inheritance, but it is a
> simplified version of multiple inheritance that avoids most of the
> complications.

They're also mostly the only kind of multiple inheritance that I would
think of using.


Oscar