netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Petr Machata <petrm@nvidia.com>
Cc: <davem@davemloft.net>, <netdev@vger.kernel.org>,
	<edumazet@google.com>, <pabeni@redhat.com>, <shuah@kernel.org>,
	<sdf@google.com>, <donald.hunter@gmail.com>,
	<linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH net-next 7/7] testing: net-drv: add a driver test for stats reporting
Date: Wed, 3 Apr 2024 06:55:32 -0700	[thread overview]
Message-ID: <20240403065532.1f2a072d@kernel.org> (raw)
In-Reply-To: <87y19uhhhx.fsf@nvidia.com>

On Wed, 3 Apr 2024 10:58:19 +0200 Petr Machata wrote:
> Also, it's not clear what "del thing" should do in that context, because
> if cfg also keeps a reference, __del__ won't get called. There could be
> a direct method, like thing.exit() or whatever, but then you need
> bookkeeping so as not to clean up the second time through cfg. It's the
> less straightforward way of going about it IMHO.

I see, having read up on what del actually does - "del thing" would
indeed not work here.

> I know that I must sound like a broken record at this point, but look:
> 
>     with build("ip link set dev %s master %s" % (swp1, h1),
>                "ip link set dev %s nomaster" % swp1) as thing:
>         ... some code which may rise ...
>     ... more code, interface detached, `thing' gone ...
> 
> It's just as concise, makes it very clear where the device is part of
> the bridge and where not anymore, and does away with the intricacies of
> lifetime management.

My experience [1] is that with "with" we often end up writing tests
like this:

	def test():
		with a() as bunch,
		     of() as things:
			... entire body of the test indented ...

[1] https://github.com/kuba-moo/linux/blob/psp/tools/net/ynl/psp.py

Nothing wrong with that. I guess the question in my mind is whether
we're aiming for making the tests "pythonic" (in which case "with"
definitely wins), or more of a "bash with classes" style trying to
avoid any constructs people may have to google. I'm on the fence on
that one, as the del example proves my python expertise is not high.
OTOH people who prefer bash will continue to write bash tests,
so maybe we don't have to worry about non-experts too much. Dunno.

  reply	other threads:[~2024-04-03 13:55 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-02  1:05 [PATCH net-next 0/7] selftests: net: groundwork for YNL-based tests Jakub Kicinski
2024-04-02  1:05 ` [PATCH net-next 1/7] netlink: specs: define ethtool header flags Jakub Kicinski
2024-04-02  1:05 ` [PATCH net-next 2/7] tools: ynl: copy netlink error to NlError Jakub Kicinski
2024-04-02  1:05 ` [PATCH net-next 3/7] selftests: net: add scaffolding for Netlink tests in Python Jakub Kicinski
2024-04-02 15:53   ` Petr Machata
2024-04-02 17:26     ` Jakub Kicinski
2024-04-03  0:09   ` David Wei
2024-04-02  1:05 ` [PATCH net-next 4/7] selftests: nl_netdev: add a trivial Netlink netdev test Jakub Kicinski
2024-04-03  0:15   ` David Wei
2024-04-02  1:05 ` [PATCH net-next 5/7] netdevsim: report stats by default, like a real device Jakub Kicinski
2024-04-03  2:51   ` David Wei
2024-04-02  1:05 ` [PATCH net-next 6/7] selftests: drivers: add scaffolding for Netlink tests in Python Jakub Kicinski
2024-04-03  3:06   ` David Wei
2024-04-02  1:05 ` [PATCH net-next 7/7] testing: net-drv: add a driver test for stats reporting Jakub Kicinski
2024-04-02 16:37   ` Petr Machata
2024-04-02 17:31     ` Jakub Kicinski
2024-04-02 17:44       ` Jakub Kicinski
2024-04-02 22:02         ` Petr Machata
2024-04-02 22:04       ` Petr Machata
2024-04-02 23:36         ` Jakub Kicinski
2024-04-03  8:58           ` Petr Machata
2024-04-03 13:55             ` Jakub Kicinski [this message]
2024-04-03 16:52               ` Petr Machata
2024-04-03 21:48                 ` Jakub Kicinski
2024-04-03  3:15       ` David Wei
2024-04-03  3:09   ` David Wei

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=20240403065532.1f2a072d@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=donald.hunter@gmail.com \
    --cc=edumazet@google.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petrm@nvidia.com \
    --cc=sdf@google.com \
    --cc=shuah@kernel.org \
    /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).