[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