I went back and reread my blog post about PuDB, and it looks like now,
after I add a configuration option for a default stringifier, the last
annoyance about PuDB to be fixed is that the relative sizes of the
variables, stack, and breakpoints views cannot be adjusted. I never
use breakpoints, rarely use the stack, and heavily use the variables,
so I would like to be able to resize these. Ideally, the size would
be saved in the configuration, but it should be modifiable from the
main user interface, not through the prefs window.
I'm going to implement this, but thought you should know about it
first, so you can warn me if you think it's a bad idea, or if you
won't like it. Basically, I plan to make the horizontal dividers
selectable (so, e.g., when you press up arrow from the top most stack
frame, it selects the "Stack" divider, not the variables list). When
you have a divider selected and you press Enter, then pressing up and
down will move it up and down (I guess pressing left and right might
as well also move the vertical divider here too). Pressing Enter
again, or one of the other shortcut keys, will deselect the divider.
I think I'm starting to get the hang of this urwid stuff and the pudb
source code, so this hopefully should not be too difficult for me to
On Wed, Jul 27, 2011 at 2:52 PM, Aaron Meurer <asmeurer(a)gmail.com> wrote:
On Wed, Jul 27, 2011 at 10:43 AM, Andreas Kloeckner
> On Tue, 26 Jul 2011 22:48:25 -0600, Aaron Meurer <asmeurer(a)gmail.com> wrote:
>> I just submitted a pull request
, which adds a new theme,
>> midnight, based on a theme of the same name from Xcode. I also
>> included other improvements, including documenting the configuration.
>> This is my finally backporting my custom hacks that I had in my GitHub
>> fork for a while (I also finally changed it so my GitHub project is
>> forked from yours).
> Great--thanks for doing that. I've already worked my way through your
>> There is one more change that I would like to make, which is to add a
>> configuration option to change the function that is called on the
>> variables (because I want to use str by default; type is completely
>> useless). Should I just allow some common ones, like type, str, repr,
>> ... (what else?), or should I have a way to define an arbitrary Python
>> function to be called on them? And if the latter, what is the best
>> way to do that?
> Sure, sounds good. There's already a per-variable option to do that, so
> your new option would just have to set the default on that. If you need
> the custom stringifier function, go ahead and implement it, otherwise
> I'd stick to the standard ones. (str(), repr(), type())
Yes, I know, as I've hacked it to use str() ever since I started using pudb :)
But now that there's configuration, it would be better to let the user
change it through that.
Custom stringifiers might be nice, as sometimes str() does indeed take
too long. For example, you could use a function like
def timeout(signum, frame, time):
raise TimeOutError("Timed out after %d seconds" % time)
def run_with_timeout(code, time):
Evaluate ``code``, timing out after ``time`` seconds.
``time`` must be an integer. The return value is whatever ``code`` returns.
# Set the signal handler and a ``time``-second alarm
signal.signal(signal.SIGALRM, lambda s, f: timeout(s, f, time))
r = eval(code)
signal.alarm(0) # Disable the alarm
return run_with_timeout("str(obj)", 1)
This will use str(), unless it takes longer than a second to compute,
in which case it will fall back to type() (unfortunately, signal.alarm
only allows second grained control, otherwise I would use 0.5 seconds
or something even smaller than that).
The question is, what's the best way to allow this? Can you put
arbitrary Python code in a .cfg file (which as far as I can tell, is
just a ini file, right?)? If not, should I just have the user define
it in some file which he can include as an option and pudb will import
the file and take the function?
> Thanks for your contributions,