[PyQt] Using Python's "print" or sys.stdout.write( "str" ) inside
of PyQt4.
Peter Lindener
lindener.peter at gmail.com
Wed Oct 1 05:33:18 BST 2008
Dear
Hans -
I gather that PyQt's problem with using "print" or
"sys.stdout.write()" inside of PyOpenGL's "GL.Widget.paint()" call back
function has something to do with Qt's redirection of the C level "stdout"
output stream?. I'm not sure exactly how PyQt handles any I/O stream
redirection logic that may need to be looked after inside of Qt, especially
where it sometime comes into interplay with call back like functions such as
in the PyQt.OpenGL example code sent in my last message. Any suggestions
as to where I might best start looking for what is going on with Python's
failure to print inside of IDE's but not outside where it works just fine,
and/or how to fix this impediment to interactive Python debugging?
-Peter
On Thu, Sep 25, 2008 at 1:40 PM, Peter Lindener <lindener.peter at gmail.com>wrote:
> Hi
> Hans-
>
> I guess there were two problems regarding the code I attached to the
> last message, and yes you are correct that this seems an issue mostly with
> using IDLE.
>
> Once I had shifted IDE's, at that moment to SciTE because I had it on my
> machine. I was missing a python error printout due to the need for a
> missing "GL." in front of the new OpenGL calls I had written. I gather one
> of the reasons the error print out was lost with IDLE had something to do
> with the code being invoked inside of "GLWidget.paintGL()". I think some of
> this may have to do with threading or call back related issues. In any case
> the "print"/stdout problem also seems to manifest from inside of SciTE....
> I have not yet tested ERIC and the other Python IDEs.
>
> In any case, now that the code has the proper name-space
> designators.... All seems well when this PyQtOpenGL example program is
> invoked stand alone. Further more, if I write to a Log file instead of
> "print" or "sys.stdout.write()"
> from inside of GLWidget.paintGL() all seems well even inside of IDLE.
> "raw_input()" in the main program flow, seems to be working inside of IDLE.
>
> I noted an anomalistic behavior as the original "hellogl.pyw" demo
> program did not, as I received it, call "window.close()", I found the
> python code completing in an orderly fashion along with it's closing
> printout, and back at the IDLE prompt...and still, the QT based OpenGL
> interactive demo window open and remaining responsive..... I'm not sure this
> is because there is more than one thread behind the scenes, or the nature of
> the Qt's signal/slot mechanism as a call-back like form of flow
> control.....still trying to grok the big picture here.
>
> I have cleaned up my code in the attached "print" bug example and added
> some comments at the front such that it might be a useful example to others
> who might be able to figure out how to make the Python environment we all
> have learned to love all that much better.
>
> Thanks for writing back!
> -Peter Lindener
>
>
>
>
> On Thu, Sep 25, 2008 at 6:14 AM, Hans-Peter Jansen <hpj at urpla.net> wrote:
>
>> Am Donnerstag, 25. September 2008 schrieb Peter Lindener:
>> > Dear
>> > PyQt4 developers -
>> >
>> > I am currently running Python 2.5,2, with IDLE version 1.2.2 under
>> > Win_XP.
>> >
>> > I'm new to using PyQt along with PyOpenGL. I have searched a bit and
>> > surprised, I was unable to find the answer to my most basic question
>> > concerning the functionality of Python's print statement when running
>> the
>> > PyQt4_OpenGL demo from Python's default interaction shell, IDLE. It
>> > seems that Qt's interaction loop freezes up once the stdout buffer is
>> > perhaps full?, in any case, using Python print statements from inside
>> a
>> > PyQt program seems to need more supporting infrastructure than that
>> > included in the attached PyQtOpenGL demo..
>> >
>> > Print statements on lines 53-62 of the attached program are currently
>> > commented out,
>> > such that it runs much like the original "hellogl.py" demo typically
>> > found on the path:
>> >
>> > C:\Python25\Lib\site-packages\PyQt4\examples\opengl.py
>> >
>> > If one reintroduces these "print" and/or "sys.stdout.write()" program
>> > lines, one does find some of the text making it back to IDLE's Python
>> > shell window... but soon enough we seem to encounter program
>> interaction
>> > death.....
>> >
>> > I have heard from some that Python's default interaction shell IDLE
>> is
>> > not all so well equipped to make all of this work, Perhaps I may need
>> to
>> > be looking at using a different development shell or IDE?, is there a
>> > common denominator as to how stdout and stdin are supposed to work in a
>> > Python environment, and do most of them handle it in the same way....it
>> > seems like some of this may still require some further development of
>> > either the IDE's involved, PyQt4 or perhaps Qt4, depending on where best
>> > to fix this problem...any suggestions?
>>
>> I do use stdout/stderr all the time (or module logging in more advanced
>> projects) but IDLE and XP are missing in the equation here. It definitely
>> sounds like an IDLE problem - try to run your scripts in a cmd shell
>> directly.
>>
>> If you are in need for an IDE, try eric. It shouldn't suffer from those
>> issues, but I always use a separate unix shell in an xterm with eric side
>> by side, since I use varying command line parameters and a huge backlog
>> buffer all the time..
>>
>> > I gather there may be an easy way to establish a Qt window for
>> > displaying the stdout stream, and /or a way to keep Python's print
>> > statements working as they typically do inside Python's interaction
>> > shell..... It would be great if likewise, some of Python's default
>> > keyboard/ "rawinput()" and sys.stdin.read()" inputput logic also could
>> > work as python programmers are familiar.. I'm sure this is covered
>> > somewhere, perhaps partly in Qt4's doc's, and perhaps somewhere in
>> PyQt's
>> > notes.... a pointer to any related documentation would be great!
>>
>> You're mixing different "universes" here, while you should decide on one,
>> at
>> least when it comes to interactive input processing. Mixing those will
>> never play well..
>>
>> > Please forgive me for not yet understanding the nuance of this, I'm
>> > still pretty new to using PyQt along with OpenGL.
>> >
>> > Thanks ahead of time for any assistance you may provide.
>> > All the best
>> > -Peter
>>
>> Cheers,
>> Pete
>> _______________________________________________
>> PyQt mailing list PyQt at riverbankcomputing.com
>> http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20081001/e5b8c8bb/attachment-0001.html
More information about the PyQt
mailing list