Re: Why do functions objfpy_new and pspy_new exist?

[Phil Muldoon <pmuldoon at redhat dot com>]

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