* [python] Pretty-printers for non-ASCII data (take 2).
@ 2009-07-06 23:03 Paul Pluzhnikov
2009-07-07 4:32 ` Jeffrey Yasskin
2009-07-07 16:24 ` Tom Tromey
0 siblings, 2 replies; 3+ messages in thread
From: Paul Pluzhnikov @ 2009-07-06 23:03 UTC (permalink / raw)
To: archer; +Cc: ppluzhnikov, jyasskin
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [python] Pretty-printers for non-ASCII data (take 2).
2009-07-06 23:03 [python] Pretty-printers for non-ASCII data (take 2) Paul Pluzhnikov
@ 2009-07-07 4:32 ` Jeffrey Yasskin
2009-07-07 16:24 ` Tom Tromey
1 sibling, 0 replies; 3+ messages in thread
From: Jeffrey Yasskin @ 2009-07-07 4:32 UTC (permalink / raw)
To: Paul Pluzhnikov; +Cc: archer
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
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [python] Pretty-printers for non-ASCII data (take 2).
2009-07-06 23:03 [python] Pretty-printers for non-ASCII data (take 2) Paul Pluzhnikov
2009-07-07 4:32 ` Jeffrey Yasskin
@ 2009-07-07 16:24 ` Tom Tromey
1 sibling, 0 replies; 3+ messages in thread
From: Tom Tromey @ 2009-07-07 16:24 UTC (permalink / raw)
To: Paul Pluzhnikov; +Cc: archer, jyasskin
>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:
Paul> Greetings,
Paul> Previous thread on this subject:
Paul> http://sourceware.org/ml/archer/2008-q4/msg00180.html
Paul> Jeffrey Yasskin suggests that in addition to gdb.Value.string we need a
Paul> gdb.Value.data(ptr, len) returning a Python 'str' object with just raw
Paul> contents of the value, which can then be passed to e.g. binascii.hexlify()
Paul> for printing.
Paul> Does that sound reasonable? I'll send a patch if it is.
If you don't need an actual Value object, we have the python-membuf
stuff that Thiago wrote a while back.
I also wonder if Value.string with the length parameter and (the yucky
part) an encoding of ISO-8859-1 would do the right thing.
If that isn't sufficient, then yeah, sounds good to me.
Tom
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-07-07 16:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-06 23:03 [python] Pretty-printers for non-ASCII data (take 2) Paul Pluzhnikov
2009-07-07 4:32 ` Jeffrey Yasskin
2009-07-07 16:24 ` Tom Tromey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).