From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24858 invoked by alias); 21 Oct 2011 00:45:02 -0000 Received: (qmail 24772 invoked by uid 22791); 21 Oct 2011 00:45:01 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta14.emeryville.ca.mail.comcast.net (HELO qmta14.emeryville.ca.mail.comcast.net) (76.96.27.212) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Oct 2011 00:44:46 +0000 Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta14.emeryville.ca.mail.comcast.net with comcast id nBSH1h0031u4NiLAECkfik; Fri, 21 Oct 2011 00:44:39 +0000 Received: from [192.168.10.125] ([75.68.58.5]) by omta21.emeryville.ca.mail.comcast.net with comcast id nCvV1h00E06m2QB8hCvVS4; Fri, 21 Oct 2011 00:55:30 +0000 Subject: Re: Python: fetch value when building gdb.Value object Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Koning In-Reply-To: Date: Fri, 21 Oct 2011 07:46:00 -0000 Cc: gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <8C455B6B-CD9C-406C-AB5E-7CE34FA3C836@comcast.net> References: <36B29E9D-F2B3-446F-AF8A-97254A3AAEE2@comcast.net> <21467A42-84A3-4DFD-83A9-28FFFB0A5C7F@comcast.net> <2F165381-183F-471F-8F55-457F08E6B008@comcast.net> <92D17899-A614-4333-87BE-E9746DFB8AB8@comcast.net> To: Tom Tromey 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 X-SW-Source: 2011-10/txt/msg00585.txt.bz2 On Oct 20, 2011, at 11:03 AM, Tom Tromey wrote: > Tom> Yes, I think so. I think the current approach is going to bite us > Tom> later. We already have bugs open about bad memory management using > Tom> gdb.Value. >=20 > Paul> Ok, I will work on that. >=20 > Thanks. >=20 > Paul> Then the other part will be a documentation change, to spell out > Paul> clearly the fact that operating on a gdb.Value type can raise an > Paul> exception at that time. For example, for a Value object v, the > Paul> expression "v+1" can result in an exception (unlike what is > Paul> usually true for Python variables of most types). >=20 > Yes, that sounds good. >=20 > Also, we can expose the laziness directly to Python. I filed a PR for > this: >=20 > http://sourceware.org/bugzilla/show_bug.cgi?id=3D13327 I can make that part of the change. How about an attribute "is_lazy", which reads as True or False, and can be = set to False (but not to other values)? paul