This is the mail archive of the
mailing list for the GDB project.
Re: Why do functions objfpy_new and pspy_new exist?
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: gdb-patches at sourceware dot org, Doug Evans <dje at google dot com>
- Date: Thu, 25 Sep 2014 11:09:11 +0100
- Subject: Re: Why do functions objfpy_new and pspy_new exist?
- Authentication-results: sourceware.org; auth=none
- References: <yjt2fvfgr95t dot fsf at ruffy dot mtv dot corp dot google dot com>
On 24/09/14 22:38, Doug Evans wrote:
> 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()
> foo_pspace = gdb.Progspace()
I can't think of a reason. But someone else might. Anyway the point
is moot (unfortunately) as we have an API promise, so they get to
> 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 don't mind cleaning up the actual "new object" code, but the calls
must remain. However we re-factor internally, the API must not loose
functionality. (I am in effect, stating this "as obvious" for the
lists and archives in case it comes up again. I am sure you already
knew about it ;)
> 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.
Being a pedant here, but this really should have gone to
gdb@sourceware? I personally prefer design decisions to be discussed
on that list. gdb-patches@ is far too high in traffic and stuff
might get missed.