This is the mail archive of the
mailing list for the Archer project.
Re: [python] Pretty-printers for non-ASCII data (take 2).
- From: Jeffrey Yasskin <jyasskin at google dot com>
- To: Paul Pluzhnikov <ppluzhnikov at google dot com>
- Cc: archer at sourceware dot org
- Date: Mon, 6 Jul 2009 21:32:02 -0700
- Subject: Re: [python] Pretty-printers for non-ASCII data (take 2).
- References: <20090706230319.6B76076BC0@localhost>
The main reason to expose any char* as a Python str object is to let
the Python code do whatever it wants with the data. Trying to
represent an array of bytes (which is what a char* is) as a unicode
object inherently obscures the data and makes it harder to write
Python printers. On the other hand, Python str objects can only handle
8-bit bytes, and the exact bytes are probably already available by
iterating the array and converting each element to an int.
<bikeshed>For the name, Python 2 uses str/unicode to describe byte
arrays and unicode character strings, while Python 3 uses bytes/str to
make the same distinction. To avoid confusion, I'd probably name the
Value methods "bytes" and "unicode". "String" is just too ambiguous.
But I won't object at all if y'all like data/string better.</bikeshed>
On Mon, Jul 6, 2009 at 4:03 PM, Paul Pluzhnikov<firstname.lastname@example.org> wrote:
> Previous thread on this subject:
> Jeffrey Yasskin suggests that in addition to gdb.Value.string we need a
> gdb.Value.data(ptr, len) returning a Python 'str' object with just raw
> contents of the value, which can then be passed to e.g. binascii.hexlify()
> for printing.
> Does that sound reasonable? I'll send a patch if it is.
> Paul Pluzhnikov