From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1353 invoked by alias); 24 Sep 2014 21:38:43 -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 1339 invoked by uid 89); 24 Sep 2014 21:38:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f201.google.com Received: from mail-pd0-f201.google.com (HELO mail-pd0-f201.google.com) (209.85.192.201) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 24 Sep 2014 21:38:41 +0000 Received: by mail-pd0-f201.google.com with SMTP id fp1so1353786pdb.0 for ; Wed, 24 Sep 2014 14:38:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type; bh=Dq4SfH5IqO9HjCfjCC4wALRFoxtwz+V5xXFtBehenqA=; b=j18F+f4mcoVXVZJ9PcBSxVhmAeXRCpR5RfZkh+aXGg1fEI6C5f/H1LwCyOf351lAFV tdbDpDuKSMRCft8/80/ZBQEcMKnQ6Fw3nCRUi4uYiXy6dPn0oS2yiFqUCRf72+WQg+ZL NxA3114V5r4TmZsBfqsQHxgPQBrfFkctKjxRvWeq9jMhbW1/Nf89EKyWMOCsFonsxN7n IZ5MCQMhFo/AhA5zX695fvhRo+mejeU1COr3Akv44D+XYSSQ1WF3K4HLrHBQ3hO77sPI 9Hi+Xo3SnvEVtWa+DMfyadTrPnGowv54XAa1AT16QaU05odeLRXcD06/2UD+OybxR9W0 OvAg== X-Gm-Message-State: ALoCoQk+n06MKZvgOiRem1l5ZJTIjM0IBA8WeClChJan8cyrFLpLe2lqMqgoBeLJ66bNdILd8XqZ5R469nGjd6C1Q4NYWSYBSsGxv+L8FgTgpKfoV3GrGUKqkt3ImG48cUBsRCePva/A3ksUViF7sQ528sm4jRe6K7u+L1vaTrFbmCbANLHrRbQ= X-Received: by 10.66.162.162 with SMTP id yb2mr6849806pab.39.1411594719975; Wed, 24 Sep 2014 14:38:39 -0700 (PDT) Received: from corpmail-nozzle1-1.hot.corp.google.com ([100.108.1.104]) by gmr-mx.google.com with ESMTPS id f102si27371yhp.7.2014.09.24.14.38.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Sep 2014 14:38:39 -0700 (PDT) Received: from ruffy.mtv.corp.google.com ([172.17.128.44]) by corpmail-nozzle1-1.hot.corp.google.com with ESMTPS id NRCwS6Wj.1; Wed, 24 Sep 2014 14:38:39 -0700 From: Doug Evans To: gdb-patches@sourceware.org Subject: Why do functions objfpy_new and pspy_new exist? Date: Wed, 24 Sep 2014 21:38:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00718.txt.bz2 Hi. Normally, python wrappers of gdb objects are created with a foo_to_foo_object function. E.g., objfile_to_objfile_object and pspace_to_pspace_object. So why do objfpy_new and pspy_new exist? [defined in py-objfile.c and py-progspace.c respectively] IOW, when would one ever usefully do something with foo_objfile = gdb.Objfile() or foo_pspace = gdb.Progspace() ? This question applies to pretty much every gdb object that can be wrapped by Python. I can imagine maybe a few objects where it would be useful to create non-gdb-wrapped python objects of some type. But I'd expect such cases to be rare. Am I missing something? I ask because we've got some duplicated code, two copies of the gdb.Objfile and gdb.Progspace constructors (objfpy_new + objfile_to_objfile_object, and pspy_new + pspace_to_pspace_object), and I think some cleanup is in order.