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 do. Aaron Meurer On Wed, Jul 27, 2011 at 2:52 PM, Aaron Meurer <[email protected]> wrote: > On Wed, Jul 27, 2011 at 10:43 AM, Andreas Kloeckner > <[email protected]> wrote: >> On Tue, 26 Jul 2011 22:48:25 -0600, Aaron Meurer <[email protected]> wrote: >>> Hi. >>> >>> I just submitted a pull request >>> https://github.com/inducer/pudb/pull/2, 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 >> requests. >> >>> 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 > > import signal > > class TimeOutError(Exception): > pass > > 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)) > signal.alarm(time) > r = eval(code) > signal.alarm(0) # Disable the alarm > return r > > def my_stringifier(obj): > try: > return run_with_timeout("str(obj)", 1) > except TimeOutError: > return type(obj) > > 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? > > Aaron Meurer > >> >> Thanks for your contributions, >> Andreas >> > _______________________________________________ Pudb mailing list [email protected] http://lists.tiker.net/listinfo/pudb
