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.