Re: [python] Pretty-printers for non-ASCII data (take 2).

[Jeffrey Yasskin <jyasskin at google dot com>]

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<ppluzhnikov@google.com> wrote:
> Greetings,
>
> Previous thread on this subject:
> http://sourceware.org/ml/archer/2008-q4/msg00180.html
>
> 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.
>
> Thanks,
> --
> Paul Pluzhnikov
>