This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 4/7] [python] API for macros: Add methods to get a gdb.Macro.

Tom Tromey <> writes:

>>>>>> "Phil" == Phil Muldoon <> writes:
> Phil> You can use a list, and then convert it to a tuple:
> Phil> PyList_AsTuple
> Sure, but that just adds another allocation.
> I don't understand what the benefit is.

There are loads of articles discussing around the old adage: "Tuples are
heterogeneous data structures, lists are homogeneous sequences" yadda
ya.  I don't really mind that distinction, and, I am not strongly swayed
one way or the other whether we should return a tuple or a list.  My
only distinction is that as a tuple is immutable, n'th element will
always be n'th element, and so can used a key to a dictionary.

So I don't want to bike-shed this, I always return a tuple where the
data won't change.  Once we return a list/tuple of macros, that
list/tuple won't change ever. To get a changed list of data, we would
have to make another call to the API.  To me, that is a constant list,
and should be a tuple.  That's the rule I use.  And it sends a
message as part of the API, "this is the data that I have now, it won't
change unless you call me again".

That being said, if the performance/memory usage question is relevant,
then yeah, converting a list to a tuple probably should be avoided.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]