[PATCH 3/3] Don't call object's (as a class) __new__ with extra arguments

David Shea dshea at redhat.com
Tue Feb 17 22:09:06 UTC 2015


On 02/17/2015 09:30 AM, Vratislav Podzimek wrote:
> The Python 3 version of the 'object' class raises an exception otherwise, the
> Python 2 version of the class ignores them anyway.
>
> Signed-off-by: Vratislav Podzimek <vpodzime at redhat.com>
> ---
>   blivet/util.py | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/blivet/util.py b/blivet/util.py
> index ecd3693..5d830df 100644
> --- a/blivet/util.py
> +++ b/blivet/util.py
> @@ -373,7 +373,7 @@ class ObjectID(object):
>       _newid_gen = functools.partial(next, itertools.count())
>   
>       def __new__(cls, *args, **kwargs):
> -        self = super(ObjectID, cls).__new__(cls, *args, **kwargs)
> +        self = super(ObjectID, cls).__new__(cls)
>           self.id = self._newid_gen() # pylint: disable=attribute-defined-outside-init
>           return self
>   

I don't like this, because it breaks the case where object is not the 
next thing in the MRO. Like in this convoluted example:

class Thing1(object):
...
class Thing2(ObjectID, Thing1):
...

Assuming both Thing1 and Thing2 start by calling super().__new__, the 
__new__ calls would be Thing2, ObjectID, Thing1, object.

But I also don't have a solution for it, since the preferable thing 
would be for each class to remove its specific arguments before passing 
down to the next class, but since we're overriding __new__ that means 
that a class not involved in ObjectID at all (Thing1) has to override 
__new__. Ugh, multiple inheritance is weird. I think the preferable 
thing would be to replace the super call with an explicit 
object.__new__(cls) and note in the doc comment ObjectID's limited 
utility as a mixin. Unless we can convert ObjectID to a metaclass or 
something.


More information about the anaconda-patches mailing list