This is the mail archive of the gdb@sourceware.org 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: repo to work on python scripting support


>>>>> "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


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