This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: [Archer] Re: [RFC][2/5] Event and event registry
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Oguz Kayral <oguzkayral at gmail dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, archer at sourceware dot org
- Date: Fri, 5 Feb 2010 15:31:20 +0400
- Subject: Re: [Archer] Re: [RFC][2/5] Event and event registry
- References: <36a35d480908230835s661fdbc2r3844a95c212a8fb@mail.gmail.com><m3eiq0x8sa.fsf@fleche.redhat.com><36a35d481002050312q4fb943fdifbfe872b128a3af5@mail.gmail.com>
> One thing I tried to achieve was to minimize the use of brackets,
> quotation marks etc. Assuming we defined an event as a dictionary, if
> a user wants to reach the stop_reason he will have to use
> stop_event["stop_reason"]. But in our case he uses
> stop_event.stop_reason, which I think is more pythonic.
For some reason, I missing the start of this conversation, so apologies
if I'm a off track in my answer.
FWIW, I agree that using a new type with attributes is more pythonic.
In the end, it's fairly equivalent anyway, but writing stop_event.stop_reason
seems easier than stop_event["stop_reason"]. I assume that the list
of attributes is statically known, so there is no risk of collision like
there was with Values (we discussed the idea of providing access to
struct/union fields via attributes, but there was a risk of collision
with the other attributes of class GDB.Value).
--
Joel