[Urwid] ANN: PuDB - the Python Urwid Debugger

Ian Ward ian at excess.org
Sat Jun 13 16:28:52 EDT 2009

Andreas Klöckner wrote:
> On Samstag 13 Juni 2009, you wrote:
>> Andreas Klöckner wrote:
>>> (Resend from subscribed address)
>>> On Mittwoch 10 Juni 2009, Ian Ward wrote:
>>>> Andreas Klöckner wrote:
>>>>> While I'm at it, two questions for Ian:
>>>>> - I'd love to be able to replace the hardcoded sys.stdout in
>>>>> raw_display. Would you take a patch? (This would allow me to implement
>>>>> an option to hijack sys.stdout. This would get rid of the annoying
>>>>> flicker on every program execution step.)
>>>> I encourage patches.  If it's general and useful I might even apply it
>>>> :-)
>>> Attached. Let me know what you think.
>> A couple questions:
>> Can you think of a use case for setting one of term_output_file,
>> term_input_file but not the other?  If not I would put them together as
>> a single parameter.
> Can't think of one.
>> What are the usage instructions for this interface?  What streams are
>> you likely to want to pass in for term_output_file and term_input_file?
> Funnily, sys.stdout and sys.stdin. The point is that I want to hijack 
> sys.stdin and sys.stdout to capture what goes into and out of them--I just 
> need Urwid to keep referring to the un-hijacked ones.
>> Andrew Psaltis is working on something similar that we have been
>> discussing on IRC.  Just attaching stdin/stdout to something else isn't
>> enough.  We also need to have a program running on that secondary
>> terminal that will catch resize events and send them back to the
>> application.
> Good point--but not an issue for the above use case. :)

Ah, that makes sense.

How about we just save sys.stdin and sys.stdout when we create the
screen (same as your code, just without the __init__ parameters) then
someone can change them to whatever they want after creating the screen?


More information about the Urwid mailing list