Why do functions objfpy_new and pspy_new exist?

Why do functions objfpy_new and pspy_new exist?

[Doug Evans]

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.

Re: Why do functions objfpy_new and pspy_new exist?

[Phil Muldoon]

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.

> ?
>
> 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.

Cheers,

Phil

Re: Why do functions objfpy_new and pspy_new exist?

[Paul_Koning]

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.

	paul

Re: Why do functions objfpy_new and pspy_new exist?

[Phil Muldoon]

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

Re: Why do functions objfpy_new and pspy_new exist?

[Doug Evans]

On Thu, Sep 25, 2014 at 3:11 PM, Phil Muldoon <pmuldoon@redhat.com> wrote:
> 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.

I know I've mentioned this before, but since the topic has come up again,
I think GDB could have a formal deprecation process that would allow
us to remove things we'd like to remove (this is for API-like things
which are harder to remove than, e.g., outdated ports).

For the case at hand, as a strawman proposal, what if we add to 7.9 a
proposal to remove the non-useful functionality with a note saying
that if no one presents a compelling case for keeping it then it will
be removed 5 releases later (or some such).  2.5 years feels long
enough for this.  I can imagine choosing a longer or short amount of
time depending on what's being deprecated.  The point is there's a
process and we use it to clean up GDB.

[This is simpler than the general one I have in mind.
I'm just throwing out the idea to see if it sticks. :-)]

Also, we could have a moratorium on adding more tp_new methods that
don't have a use-case.
That we can do today.

Re: Why do functions objfpy_new and pspy_new exist?

[Phil Muldoon]

On 25/09/14 23:07, Doug Evans wrote:
>>
>>
>> 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.
>
> I know I've mentioned this before, but since the topic has come up again,
> I think GDB could have a formal deprecation process that would allow
> us to remove things we'd like to remove (this is for API-like things
> which are harder to remove than, e.g., outdated ports).
>
> For the case at hand, as a strawman proposal, what if we add to 7.9 a
> proposal to remove the non-useful functionality with a note saying
> that if no one presents a compelling case for keeping it then it will
> be removed 5 releases later (or some such).  2.5 years feels long
> enough for this.  I can imagine choosing a longer or short amount of
> time depending on what's being deprecated.  The point is there's a
> process and we use it to clean up GDB.
>
> [This is simpler than the general one I have in mind.
> I'm just throwing out the idea to see if it sticks. :-)]
>
> Also, we could have a moratorium on adding more tp_new methods that
> don't have a use-case.
> That we can do today.

That sounds like a plausible plan.  The next step is documenting it in
the wiki and/or other places.

Cheers

Phil

Re: Why do functions objfpy_new and pspy_new exist?

[Stan Shebs]

On 9/25/14, 3:07 PM, Doug Evans wrote:
[...]
> 
> I know I've mentioned this before, but since the topic has come up again,
> I think GDB could have a formal deprecation process that would allow
> us to remove things we'd like to remove (this is for API-like things
> which are harder to remove than, e.g., outdated ports).

Nominally, the existing process is as described at

https://sourceware.org/gdb/wiki/Internals%20Obsoleting-code

We've also done "deprecate in one release, remove in the next", and
added "deprecated_" onto function names and such.  Empirically, it
hasn't created the desired urgency - people have been content to keep
calling deprecated_foo for many years after its deprecation. :-)

Stan
stan@codesourcery.com