From: Cleber Rosa <crosa@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>, Amador Pahim <apahim@redhat.com>
Cc: qemu-devel@nongnu.org, kwolf@redhat.com, ldoktor@redhat.com,
ehabkost@redhat.com, armbru@redhat.com, mreitz@redhat.com,
famz@redhat.com
Subject: Re: [Qemu-devel] [PATCH v4 1/2] qemu.py: make 'args' public
Date: Tue, 25 Jul 2017 11:30:16 -0400 [thread overview]
Message-ID: <fe45a297-3f65-e212-90fc-33dd6d48a2f0@redhat.com> (raw)
In-Reply-To: <20170725133708.GE23343@stefanha-x1.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2974 bytes --]
On 07/25/2017 09:37 AM, Stefan Hajnoczi wrote:
> On Mon, Jul 24, 2017 at 02:44:37PM +0200, Amador Pahim wrote:
>> Let's make args public so users can extend it without feeling like
>> abusing the internal API.
>
> Nothing is abusing an internal API. PEP8 describes the difference
> between public (no underscore), protected aka subclass API (single
> underscore), and private fields (single or double underscore):
>
> https://www.python.org/dev/peps/pep-0008/
>
> _args is a protected field. It is perfectly normal for a subclass to
> access a protected field in its parent class.
>
Right, which means that instances should not be using it. I guess
there's a clear conflict of what is assumed to be the intended use for
this class.
I can see the value in using it *directly*, and I can also see changing
the QEMU args as a requirement.
>> Signed-off-by: Amador Pahim <apahim@redhat.com>
>> Reviewed-by: Fam Zheng <famz@redhat.com>
>> ---
>> scripts/qemu.py | 10 +++++-----
>> tests/qemu-iotests/iotests.py | 18 +++++++++---------
>> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> Please don't do this, it encourages code duplication. Now arbitrary
> users can start accessing the public field directly instead of adding a
> reusable interfaces like add_monitor_telnet(), add_fd(), etc.
>
Judging from tests/qemu-iotests/iotests.py:VM and your comment above, I
assume you see value in simple wrappers such as:
def add_device(self, opts):
self._args.append('-device')
self._args.append(opts)
return self
I honestly do not see any value here. I do see value in other wrappers,
such as add_drive(), in which default values are there for convenience,
and a drive count is kept. In the end, my point is that the there are
cases when a wrapper is just an annoyance and provides nothing more than
the illusion of a better design.
If "args" is not made public, wrappers with no real value will start to
be proposed, either within the test's own subclass (like in
tests/qemu-iotests/iotests.py:VM) or will make its way to
scripts/qemu.py:QEMUMachine.
What you describe as "adding reusable interfaces" can be seen both as a
blessing if they're really well designed interfaces, or a curse if
they're something a test writer *has* to write while a test is being
written to get around the fact that "args" is not available.
Extending on the "add_device()" example, how would you feel about
something like:
def add_arg(self, arg, opts=None):
self._args.append(arg)
if opts is not None:
self._args.append(opts)
FIY, I have a bad feeling about it, but it's quite comparable to
add_device(), and it keeps "args" private.
--
Cleber Rosa
[ Sr Software Engineer - Virtualization Team - Red Hat ]
[ Avocado Test Framework - avocado-framework.github.io ]
[ 7ABB 96EB 8B46 B94D 5E0F E9BB 657E 8D33 A5F2 09F3 ]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2017-07-25 15:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-24 12:44 [Qemu-devel] [PATCH v4 0/2] scripts/qemu.py fixes and cleanups Amador Pahim
2017-07-24 12:44 ` [Qemu-devel] [PATCH v4 1/2] qemu.py: make 'args' public Amador Pahim
2017-07-25 13:37 ` Stefan Hajnoczi
2017-07-25 14:41 ` Amador Pahim
2017-07-25 15:30 ` Cleber Rosa [this message]
2017-07-26 17:35 ` Stefan Hajnoczi
2017-07-26 18:34 ` Cleber Rosa
2017-07-27 7:39 ` Amador Pahim
2017-07-27 15:15 ` Amador Pahim
2017-07-24 12:44 ` [Qemu-devel] [PATCH v4 2/2] qemu.py: cleanup and fixes Amador Pahim
2017-07-25 13:45 ` Stefan Hajnoczi
2017-07-25 14:45 ` Amador Pahim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fe45a297-3f65-e212-90fc-33dd6d48a2f0@redhat.com \
--to=crosa@redhat.com \
--cc=apahim@redhat.com \
--cc=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=ldoktor@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).