Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Paul Koning <paulkoning@comcast.net>
To: Doug Evans <dje@google.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	tromey@redhat.com, gdb-patches@sourceware.org
Subject: Re: [RFA] Python: raise exception on field-related gdb.Type methods if it's not struct or union
Date: Wed, 09 Nov 2011 01:53:00 -0000	[thread overview]
Message-ID: <DFE3D86A-A620-41AB-AB3C-FBC7111F32DA@comcast.net> (raw)
In-Reply-To: <CADPb22RGzLX6_GKXk4KqCBtLE2Z12gn7Hdhokd72WgqxKNeCsg@mail.gmail.com>


On Nov 8, 2011, at 7:29 PM, Doug Evans wrote:

> On Tue, Nov 8, 2011 at 1:40 PM, Paul Koning <paulkoning@comcast.net> wrote:
>> ...
>> I found the answer to that question with a bit of searching.   Attached is a patch that raises an exception (TypeError) for len() and all the field reference methods if the type isn't struct or union.
> 
> I wasn't sure using as_number here was kosher.  "works for me" if it
> does the job.

Yes, the book (Python Reference) says that if __nonzero__ is defined (which is what this does) then that is used for truth testing, otherwise __len__ is, and if neither is defined then the thing in question is always True.

> 
>> Does this need new testcases?
> 
> Yeah, I think so.
> Verify "not type" DTRT, and affected operations on scalar types flag
> the right error.
> 
> One question I have is: for struct types that have an empty field list
> (say an empty struct), what's the result of "not type".  True or
> False?  I can argue either way, and I'm not sure what's the best
> answer, long term.
> [But then again, my python fu isn't enough to be comfortable with any
> conclusion I reach.]

The way I wrote it, a truth test on a gdb.Type object is always True, so the answer to the question is "False".  It doesn't matter if the type is scalar, or struct, or for struct whether it has fields or not.  The Python Reference says that objects that define neither a nonzero nor a len operation are always True.  That applies, for example, to the Python builtin object "type", and since gdb.Type is vaguely like "type" I figured the same behavior should apply.  
> 
> Thanks very much for doing this!
> 
> btw, a couple of nits:
> 1) Please put a blank line between a function's comment and its definition.
> There are several occurrences of this.

Oops, yes, I should have remembered that.
> 2) Can you rename typy_deref?  typy_get_struct works for me, I'm sure
> there's a better name.
>    "deref" feels confusing, one can deref a pointer to anything, not
> just structs/unions, and
>    the function doesn't necessarily do a dereference.

I like the name you mentioned.  Will do.

	paul


  reply	other threads:[~2011-11-09  1:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-16  4:09 Python: add field access by name and standard python mapping methods to gdb.Type Paul Koning
2011-09-16  7:36 ` Eli Zaretskii
2011-09-16 10:47 ` Phil Muldoon
2011-09-16 14:57   ` Paul Koning
2011-09-16 14:57     ` Phil Muldoon
2011-09-16 15:41   ` Paul Koning
2011-09-23 17:21     ` Doug Evans
2011-09-26 17:15       ` [RFA] " Paul Koning
2011-09-28 19:25         ` Doug Evans
2011-09-28 20:41           ` Paul Koning
2011-10-04 15:14             ` Tom Tromey
2011-10-04 15:30               ` Paul Koning
2011-10-04 15:42                 ` Eli Zaretskii
2011-10-04 15:56                   ` Paul Koning
2011-11-04 17:42                     ` Doug Evans
2011-11-04 20:41                       ` Paul Koning
2011-11-04 23:05                         ` Doug Evans
2011-11-05 14:36                           ` Paul Koning
2011-11-05 21:04                             ` Doug Evans
2011-11-08 21:40                               ` [RFA] Python: raise exception on field-related gdb.Type methods if it's not struct or union Paul Koning
2011-11-09  0:29                                 ` Doug Evans
2011-11-09  1:53                                   ` Paul Koning [this message]
2011-11-09 18:10                                   ` Paul Koning
2011-11-15 19:01                                     ` [PING] " Paul Koning
2011-11-15 20:57                                       ` Doug Evans
2011-11-15 21:21                                         ` Paul Koning

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DFE3D86A-A620-41AB-AB3C-FBC7111F32DA@comcast.net \
    --to=paulkoning@comcast.net \
    --cc=dje@google.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox