Why do functions objfpy_new and pspy_new exist?
Phil Muldoon
pmuldoon@redhat.com
Thu Sep 25 21:29:00 GMT 2014
On 25/09/14 16:18, Paul_Koning@dell.com wrote:
>
> On Sep 25, 2014, at 6:09 AM, Phil Muldoon <pmuldoon@redhat.com> wrote:
>
>> On 24/09/14 22:38, Doug Evans wrote:
>>> 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()
>>
>> 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
>> stay. Forever.
>
> I would usually agree, but I would make an exception if the API function in question does not produce anything that can be used for any plausible purpose. That may be the case here.
I really don't disagree with you Paul. But we have to prove
plausible, and perhaps wait until someone turns up and says "oh I have
this plausible scenario". Perhaps a patch to gdb-patches and a
suitable wait is OK, (though I am not sure GDB Python users read that
list). It is, trust me, a frequent frustration for me to add
yet-another-keyword-while-preserving-original-behavior, especially
with the Python 2.x and 3.x as well. It is, I think, becoming
impossible to manage.
I don't have an objection beyond does this break the API promise.
That's all I care about. I did not make that promise -- these
decisions were made before my time. But I think we should uphold it.
Maybe if GDB future releases requires only Python 3.x in future we can
amend that.
Cheers,
Phil
More information about the Gdb-patches
mailing list