Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Paul Koning <Paul_Koning@dell.com>
To: jimb@red-bean.com
Cc: tromey@redhat.com,     bauerman@br.ibm.com,     gdb@sourceware.org
Subject: Re: repo to work on python scripting support
Date: Thu, 27 Mar 2008 17:57:00 -0000	[thread overview]
Message-ID: <18411.51780.421521.894893@pkoning-laptop.equallogic.com> (raw)
In-Reply-To: <8f2776cb0803261540j19d9f591k93cdf41233dd67df@mail.gmail.com>

>>>>> "Jim" == Jim Blandy <jimb@red-bean.com> writes:

 Jim> Python decorators seem to be in the latest python, at least:
 Jim> http://docs.python.org/ref/function.html

 Jim> The discussion Tom linked to was back in 2004.

 Jim> Decorators would be perfect for this, I think:

 Jim> @Gdb.interactive (Gdb.Expr, Gdb.Expr) def strcmp (str1, str2):
 Jim> // compare strings

 Jim> Easy squeezy.

Decorators showed up in Python 2.4, which was released in November
2004.  And yes, that syntax or something like it can do what you
described. 

I have the impression that decorators are a fairly obscure part of the
language.  That impression may be wrong...

I'm still not convinced that adding Elisp-style "interactive"
decoration to Python is a good idea.  (If it's a good idea, maybe it
should be a Python PEP, added to the base language, as opposed to a
GDB-specific extension.)  Yes, if you have programmed in Elisp (I
have) then it will be familiar, and it might feel like a handy
convenience.  If you're not an Elisp programmer, the likely reaction
is "I don't recognize this style of Python".

Clearly, Python embedded in/with GDB needs to have hooks into GDB.
The obvious style that will be familiar to programmers in any language
is by way of funtion calls -- for example "gdb.eval_expr(string)".

A less obvious way but part of existing Python -- albeit a part
probably not all that familiar to the community -- is decorators.
Those avoid the need to do gdb.xxx function calls at function entry
(though you still need them, for use at spots other than function
entry).

The least desirable approach is to have a new non-Python way of
describing argument processing -- things like the doc string parsing
or other similar things that have been talked about.  I think those
are a bad idea because you end up with something that isn't Python, is
GDBython... :-)

I still think just gdb.xxx() functions are sufficient and intuitive.

But if you want to do the function entry stuff, then decorators look
like the right way to do it.  They can be implemented with
semi-straightforward Python code and the gdb.xxx() functions that you
need anyway (a nice exercise for the reader).

	paul


  reply	other threads:[~2008-03-27 16:26 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-16  0:42 Thiago Jung Bauermann
2008-03-16  2:55 ` Tom Tromey
2008-03-24 17:16   ` Thiago Jung Bauermann
2008-03-25 11:45     ` Tom Tromey
2008-03-25 13:53       ` Daniel Jacobowitz
2008-03-25 18:37         ` Jim Blandy
2008-03-25 18:52           ` Daniel Jacobowitz
2008-03-25 18:53             ` Jim Blandy
2008-03-25 19:18             ` Tom Tromey
2008-03-27  6:41               ` Jim Blandy
2008-03-27 17:57                 ` Paul Koning [this message]
2008-03-25 19:31           ` Paul Koning
2008-03-25 20:18             ` Tom Tromey
2008-03-25 20:31               ` Paul Koning
2008-03-26  3:23                 ` Tom Tromey
2008-03-26 12:55                 ` Jim Blandy
2008-03-26 17:29                   ` Paul Koning
2008-03-26 17:58                     ` Daniel Jacobowitz
2008-03-26 18:41                     ` Tom Tromey
2008-03-26 20:04                       ` Paul Koning
2008-03-26 22:45                     ` Jim Blandy
2008-03-26 18:05       ` Doug Evans
2008-03-26 18:13         ` Daniel Jacobowitz
2008-03-26 18:25           ` Tom Tromey
2008-03-26 18:41             ` Daniel Jacobowitz
2008-03-26 18:55               ` Tom Tromey
2008-03-26 20:57                 ` Daniel Jacobowitz
2008-03-26 21:01                 ` Thiago Jung Bauermann
2008-03-27 14:11           ` Jim Blandy
2008-03-27 16:49             ` Paul Koning
2008-03-26 18:23         ` Tom Tromey

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=18411.51780.421521.894893@pkoning-laptop.equallogic.com \
    --to=paul_koning@dell.com \
    --cc=bauerman@br.ibm.com \
    --cc=gdb@sourceware.org \
    --cc=jimb@red-bean.com \
    --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