From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26416 invoked by alias); 7 Feb 2013 23:03:35 -0000 Received: (qmail 26394 invoked by uid 22791); 7 Feb 2013 23:03:34 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com) (209.85.215.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Feb 2013 23:03:27 +0000 Received: by mail-la0-f41.google.com with SMTP id fo12so3214135lab.14 for ; Thu, 07 Feb 2013 15:03:25 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.136.20 with SMTP id pw20mr2922362lab.16.1360278205092; Thu, 07 Feb 2013 15:03:25 -0800 (PST) Received: by 10.114.64.40 with HTTP; Thu, 7 Feb 2013 15:03:24 -0800 (PST) In-Reply-To: References: <87y5f1w6xc.fsf@fleche.redhat.com> Date: Thu, 07 Feb 2013 23:03:00 -0000 Message-ID: Subject: Re: [RFC - Python Scripting] New method gdb.Architecture.disassemble From: Matt Rice To: Siva Chandra Cc: Tom Tromey , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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: 2013-02/txt/msg00202.txt.bz2 On Wed, Feb 6, 2013 at 5:11 PM, Siva Chandra wrote: > On Wed, Feb 6, 2013 at 3:18 PM, Siva Chandra wrote: >> Based on what Matt says in his comments, it seems like a leaf row can >> look like one of these 3 possibilities: >> >> 1. [1, 2, 3] >> 2. ['a' : 1, 'b': 2, 'c': 3] >> 3. ['a': 1, 'a': 2, 'a': 3] >> >> 1 and 2 can be encapsulated with fundamental Python data structures. I >> am not aware of any fundamental Python data structure which can >> capture 3. So, is using a helper class called LabelValuePair a good >> idea? With this, all leaf rows can be lists whose elements are either >> all values, or are all LabelValuePairs: [value, value, value] or >> [LabelValuePair, LabelValuePair, LabelValuePair]. Does this sound >> reasonable? We can always go in for a list of single element dicts, >> but I think that kind of makes it ugly. LabelValuePair can look like >> this (in its Python form): >> >> class LabelValuePair(object): >> def __init__(self, label, value): >> self.label = label # not a writable attribute >> self.value = value # not a writable attribute > > Or, could it be a named tuple: > http://docs.python.org/2.7/library/collections.html#collections.namedtuple > The down side is that they are available only on Python 2.4 and higher. I definitely agree that these make it possible to do the py-out stuff without the headache of modifying existing ui-out callers which is desirable, and turning it into {'a': (1, 2, 3)} doesn't really achieve that due to the single 'uiout_list_type' entry point currently available. one nice thing about the latter is that any python version can parse it via 'literal_eval'. which means if someone wanted to replace mi with py-out as a wire protocol they need to share either the named_tuple stuff, or the LabelValuePair object code on both the gdb and py-out client side. so, my preference had been to represent duplicate keys as dict with a list value just because it makes parsing dead simple/can just use a stock python, that said I definitely see the appeal of a custom class or named tuple, so I'm sort of on the fence on this one.