mirror of
https://gitlab.com/libvirt/libvirt-python.git
synced 2025-12-07 04:23:47 +03:00
8c800b0adf
This reverts commitf4be03b330. While object.__init__() does not expect any additional arguments, this construct is required for Pythons multiple inheritance implementation. The original author Wojtek Porczyk <woju@invisiblethingslab.com> explained is this way: > I'm sorry I didn't notice this earlier, but the commitf4be03b3dated > 2020-04-20 [0] is wrong. The super().__init__(*args, **kwargs) in > Callback.__init__ was there on purpose, because of how Python's inheritance in > new-style classes works. > > Let me explain this a bit, because it is not obvious. > > Suppose you had diamond inheritance like this: > > class A(object): pass > class B(A): pass > class C(A): pass > class D(B,C): pass > > And those classes needed a common function with varying arguments: > > class A(object): > def spam(self, a): print(f'A: {a}') > class B(A): > def spam(self, b): print(f'B: {b}') > class C(A): > def spam(self, c): print(f'C: {c}') > class D(B,C): > def spam(self, d): print(f'D: {d}') > > The way to call all parent's functions exactly once (as per MRO) and accept > all arguments and also forbid unknown arguments is to accept **kwargs > everywhere and pass them to super().spam(): > > class A: > def spam(self, a): > print(f'A: {a}') > class B(A): > def spam(self, b, **kwargs): > print(f'B: {b}') > super().spam(**kwargs) > class C(A): > def spam(self, c, **kwargs): > print(f'C: {c}') > super().spam(**kwargs) > class D(B, C): > def spam(self, d, **kwargs): > print(f'D: {d}') > super().spam(**kwargs) > > Let's run this: > > >>> B().spam(a=1, b=2) > B: 2 > A: 1 > >>> D().spam(a=1, b=2, c=3, d=4) > D: 4 > B: 2 > C: 3 > A: 1 > > You may notice that super() in B.spam refers to two different classes, either > A or C, depending on inheritance order in yet undefined classes (as of B's > definition). > > That's why the conclusion that super() in Callback.__init__ refers to object > is wrong. In this example, spam=__init__, A=object, B=Callback and C and D are > not yet written, but theoretically possible classes that could be written by > someone else. Why would they be needed, I don't know, but if someone writes > them, s/he would be out of options to invent new arguments to C.__init__. > > Note that super().__init__(*args, **kwargs) when super() refers to object > isn't harmful, and just ensures that args and kwargs are empty (i.e. no > unknown arguments were passed). In fact, this is exactly why object.__init__() > takes no arguments since Python 2.6 [1][2], as you correctly point out in the > commit message. > > I don't think this breaks anything (I very much doubt anyone would need to > write code that would trigger this), nevertheless, as the commit is both > pointless and wrong, and as the original author of libvirtaio I'd like to ask > for this commit to be reverted. If this breaks some static analysis tool, > could you just suppress it for this particular line? > > > [0]f4be03b330> [1] https://bugs.python.org/issue1683368 > [2] https://docs.python.org/3/whatsnew/2.6.html#porting-to-python-2-6 > (fourth point) > Signed-off-by: Philipp Hahn <hahn@univention.de>
Libvirt Python Binding README
=============================
This package provides a python binding to the libvirt.so,
libvirt-qemu.so and libvirt-lxc.so library APIs.
It is written to build against any version of libvirt that
is 0.9.11 or newer.
This code is distributed under the terms of the LGPL version
2 or later.
The module can be built by following the normal python module
build process
python setup.py build
sudo python setup.py install
or to install as non-root
python setup.py build
python setup.py install --user
If python-nose is installed, you can test the package with
python setup.py test
A makefile shim is provided so that you can do
make && make check
rather than directly invoking setup.py.
As of libvirt 1.2.6, it is possible to develop against an uninstalled
libvirt.git checkout, by setting PKG_CONFIG_PATH and LD_LIBRARY_PATH
environment variables to point into that libvirt tree; you can even
automate this by using libvirt's run script:
/path/to/libvirt/run python setup.py build
Patches for this code should be sent to the main libvirt
development mailing list
http://libvirt.org/contact.html#email
To send patches, it is strongly recommended to use the
'git send-email' command.
Make sure the mails mention that the patch is for the python
binding. This can be done by setting a config parameter in the
local git checkout
git config format.subjectprefix "PATCH python"