Text-based data inspector for Python?

[kj]

I've only recently started programming in Python, trying to wean
myself from Perl. One of the things I *really* miss from Perl is
a 100% mouse-free data inspector, affectionally known as the Perl
debugger, PerlDB, or just perl -d. With it I can examine the most
elaborate data structures with ease:

DB<234> |x %one_most_elaborate_data_structure

....and miles of data, paged for leisurely browsing, lie at my feet.

And, since it's text-based, I can run it within a shell in Emacs,
and transfer anything I want between it and an editing buffer
without even a THOUGHT of touching the filthy mouse! If there's
a greater joy in life I have yet to find it.

Now, I have NO DOUBT in my mind WHATSOEVER that a plethora of simply
amazing GRAPHICAL data inspectors (or the equivalent) exist for
Python, with exquisite features, animation, sound effects,
scratch-and-sniff, massage, built-in spiritual advisor, you-name-it.
Beautiful stuff, no doubt.

But an old geezer like me likes to keep his knobby hands on the
keyboard at all times, so that his arthritic shoulder keeps quiet...

So. Can I hope to find a text-based data inspector for Python?

kynn

 

[Terry Jones]

kj> I've only recently started programming in Python, trying to wean
kj> myself from Perl. One of the things I *really* miss from Perl is
kj> a 100% mouse-free data inspector, affectionally known as the Perl
kj> debugger, PerlDB, or just perl -d. With it I can examine the most
kj> elaborate data structures with ease:

You actually liked the perl debugger... gasp! OK, I used it too, but it
left a few things to be desired (the mouse was not one).

kj> And, since it's text-based, I can run it within a shell in Emacs, and
kj> transfer anything I want between it and an editing buffer without even
kj> a THOUGHT of touching the filthy mouse! If there's a greater joy in
kj> life I have yet to find it.

I use M-x pydb to debug python from inside emacs. I like it more than the
straight pdb as it's a bit more like gdb.

In pydb (and pdb) there's p and pp to print and pretty print a python
object. They work pretty well & there's no need for the mouse.

kj> NOTE: In my address everything before the first period is backwards;
kj> and the last period, and everything after it, should be discarded.

Nice. See http://www.fluidinfo.com/terry/2007/10/31/stagnant-email-address-arms-race/

Terry

 

[Paddy]

I've only recently started programming in Python, trying to wean
myself from Perl. One of the things I *really* miss from Perl is
a 100% mouse-free data inspector, affectionally known as the Perl
debugger, PerlDB, or just perl -d. With it I can examine the most
elaborate data structures with ease:

DB<234> |x %one_most_elaborate_data_structure

...and miles of data, paged for leisurely browsing, lie at my feet.

And, since it's text-based, I can run it within a shell in Emacs,
and transfer anything I want between it and an editing buffer
without even a THOUGHT of touching the filthy mouse! If there's
a greater joy in life I have yet to find it.

Now, I have NO DOUBT in my mind WHATSOEVER that a plethora of simply
amazing GRAPHICAL data inspectors (or the equivalent) exist for
Python, with exquisite features, animation, sound effects,
scratch-and-sniff, massage, built-in spiritual advisor, you-name-it.
Beautiful stuff, no doubt.

But an old geezer like me likes to keep his knobby hands on the
keyboard at all times, so that his arthritic shoulder keeps quiet...

So. Can I hope to find a text-based data inspector for Python?

kynn

I tend to do the following at the python prompt:

from pprint import pprint as pp

Then I can:

pp(my_data)


- Paddy.

 

[kj]

I tend to do the following at the python prompt:

from pprint import pprint as pp

Thanks, that's a good one to know, but isn't there a way to automate
it???

I looked around, but I couldn't find the name of any *rc-type file
that would hold interpreter customizations. The closest I found
was ~/.pythonrc.py, but that still requires doing "import user" at
every interpreter session. (As annoyances go, this is certainly
a minor one, but with me the psychological effects of such small
annoyances gets magnified in proportion to how unnecessary they
seem.) Plus, I'm not sure that it'd be such a great idea to execute
code intended to customize the interpreter every time that the user
module gets loaded...

kynn

 

[kj]

You actually liked the perl debugger... gasp!

Still do, in fact!.

OK, I used it too, but it
left a few things to be desired...

I'd love to read your thoughts on the matter. My biggest complain
about it is that its underlying code is very poorly designed and
it's having a difficult time keeping up with the language. With
each new version of Perl it springs new leaks, unfortunately. For
example, it's much worse than Perl itself at dealing with Unicode.
....And its documentation is probably the worst of all of the core
Perl docs. Let's see, what else...? Nothing else comes to mind
at the moment.

I use M-x pydb to debug python from inside emacs. I like it more than the
straight pdb as it's a bit more like gdb.

In pydb (and pdb) there's p and pp to print and pretty print a python
object. They work pretty well & there's no need for the mouse.

Thank you much for the tip. I just skimmed over its documentation
and I'm looking forward to using it. The one thing I couldn't
find, and would greatly miss if not available, is the ability to
set breakpoints by inserting a particular indication right in the
code. In the Perl debugger one can insert something like the
following anywhere in the code:

$DB::single = 1;

When such a line executes, the debugger immediately switches to
single-step mode. It's a very flexible technique, and I like it
a lot more than setting breakpoints the "usual" way (i.e. "b [line]
[condition]"). For example, for a conditional breakpoint one can
do something like:

$DB::single = some_boolean_test();

Or if one isn't sure exactly when one wants to stop at the location,
one can just write:

$DB::single = ( $::SOME_GLOBAL_VARIABLE || 0 );

(The "|| 0" is there so that the debugger won't complain over
assigning an undefined RHS in the assignment.) If while stopped
at some other breakpoint, and perhaps having inspected some data,
we decide that it's time to stop at this line, we just assign 1 to
the global, hit the old "c"(ontinue), and one's there.

In fact, setting $DB::single is the only way I know to have a
breakpoint in code that executes at compile time (such as anything
in a BEGIN block and any top-level code in modules imported via
the "use" directive). Setting a breakpoint with b at such points
and restarting the program won't work. Extremely handy.

Maybe something like this (or even better!) is already possible in
pydb, but I couldn't find it. If it is, though, I'll be very
psyched.

kynn

 

[Paddy]

Thanks, that's a good one to know, but isn't there a way to automate
it???

I looked around, but I couldn't find the name of any *rc-type file
that would hold interpreter customizations. The closest I found
was ~/.pythonrc.py, but that still requires doing "import user" at
every interpreter session. (As annoyances go, this is certainly
a minor one, but with me the psychological effects of such small
annoyances gets magnified in proportion to how unnecessary they
seem.) Plus, I'm not sure that it'd be such a great idea to execute
code intended to customize the interpreter every time that the user
module gets loaded...

kynn

python -h gives me:
...
Other environment variables:
PYTHONSTARTUP: file executed on interactive startup (no default)
...

- Paddy.

 

[kj]

python -h gives me:
...
Other environment variables:
PYTHONSTARTUP: file executed on interactive startup (no default)
...

Sweet. Thanks!

kynn

 

[Gabriel Genellina]

The one thing I couldn't
find, and would greatly miss if not available, is the ability to
set breakpoints by inserting a particular indication right in the
code. In the Perl debugger one can insert something like the
following anywhere in the code:

$DB::single = 1;

When such a line executes, the debugger immediately switches to
single-step mode. It's a very flexible technique, and I like it

I think that pdb.set_trace() does what you want.

 

[Gabriel Genellina]

The one thing I couldn't
find, and would greatly miss if not available, is the ability to
set breakpoints by inserting a particular indication right in the
code. In the Perl debugger one can insert something like the
following anywhere in the code:

$DB::single = 1;

When such a line executes, the debugger immediately switches to
single-step mode. It's a very flexible technique, and I like it

I think that pdb.set_trace() does what you want.