From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94999 invoked by alias); 12 Sep 2018 22:01:49 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 94985 invoked by uid 89); 12 Sep 2018 22:01:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Question X-HELO: gateway32.websitewelcome.com Received: from gateway32.websitewelcome.com (HELO gateway32.websitewelcome.com) (192.185.145.18) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Sep 2018 22:01:47 +0000 Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 0447E467AAF for ; Wed, 12 Sep 2018 17:01:46 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id 0DCjgKziGkBj60DCjgW4KB; Wed, 12 Sep 2018 17:01:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=sZuD31qqR3zWNKalQUO8Axp765P4ksAoiPG0qAzehGE=; b=vIUS4nhGgPNUDtjd79ZuuRM1mt RjHuBlT3DlctPrGVSXVEKlgbI3qNvkcr0hx24vh15xpn2zIFIXhI05G0t/F3VhMB2pqoF1dvsnuaP 2weVSAi7N4orQnwiZNVUbtYeO; Received: from hca.ear2.denver1.level3.net ([4.14.116.118]:36182 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1g0DCj-002EqV-MM; Wed, 12 Sep 2018 17:01:45 -0500 From: Tom Tromey To: Simon Marchi Cc: Subject: Re: [PATCH 2/3] python: Add Progspace.objfiles method References: <20180912193617.16523-1-simon.marchi@ericsson.com> <20180912193617.16523-2-simon.marchi@ericsson.com> Date: Wed, 12 Sep 2018 22:01:00 -0000 In-Reply-To: <20180912193617.16523-2-simon.marchi@ericsson.com> (Simon Marchi's message of "Wed, 12 Sep 2018 15:36:16 -0400") Message-ID: <874leujrxz.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-09/txt/msg00378.txt.bz2 >>>>> "Simon" == Simon Marchi writes: Simon> Question: Simon> When we try to access a property of an Inferior object that has Simon> become invalid, for example, we raise an exception ("Inferior no longer Simon> exists."). When doing the same with a Progspace object, we return None Simon> (the only case for now is its filename property). For Simon> Progspace.objfiles(), I made it return None too, but perhaps it should Simon> throw an exception instead? Especially that None is not iterable, so Simon> trying to do: Simon> for obj in pspace.objfiles(): Simon> ... Simon> will fail horribly if we return None... so should I introduce a macro Simon> similar to INFPY_REQUIRE_VALID? There are two approaches to modeling gdb objects in the Python layer. One is taken by objects like Value whose lifetime can be arbitrarily "extended". For these objects, Python simply holds a reference to the underlying gdb object. The other approach is for objects whose lifetime can be controlled by the user or other external (to Python) events. For example, a breakpoint can be deleted by the user, leaving behind the gdb.Breakpoint representation. For these we have generally had the Python object keep a sort of weak reference to the gdb object; when the gdb object is destroyed, the Python wrapper enters a special invalid state. These objects have an is_valid method; and generally all other methods and attributes throw an exception if the object is invalid -- but I think this is not a hard-and-fast rule and can be broken where there is an obvious decent non-exception result. In sum I think INFPY_REQUIRE_VALID is fine if you happen to need it at some spot in the inferior wrapper. I wouldn't go out of my way to avoid it. Normally Python code has to know not to work with an invalid object (and anyway why would it want to); but I think in this case, I would be fine with objfiles() returning an empty sequence. That is what my old patch did, I would assume intentionally, though I don't recall. Finally, I have another ancient and unfinished series that adds a bunch of methods to Inferior. If you're working in this area I can send it; I'd be happy to rebase it. Tom