[IPython-User] IPython included in Spyder v1.1.0
Mon Sep 6 03:24:31 CDT 2010
I completely forgot to give some feedback regarding this threading
issues which were causing bugs when integrating IPython into Spyder.
These problems occured only on Windows platforms: IPython's internal
main loop was blocking the GUI event loop, hence freezing any opened
window/dialog box, when calling a file open/save dialog. Example: when
clicking on the 'Save as' button of a Matplotlib's figure, the figure
was frozen until the user hit the <Enter> key in the IPython
console... so, quite an ugly bug.
In the meantime, I found a workaround, maybe as ugly as the bug itself
but it works like a charm. Actually, I'm calling the win32 api
function 'GetOpenFileNameW': the file dialog does not pop-up and
return an error which is silently handled. And so the win32 file
system thread is initialized and the next time this kind of file
dialog pops-up, the GUI is not freezing.
FYI, here is the workaround implementation:
import win32gui, win32api
# This error is triggered intentionally
# Unfortunately, pywin32 is not installed...
So, IPython has now been successfully integrated to Spyder v1.1 and
v2.0 (for two months now, sorry for the late announcement!) on all
2010/6/22 Brian Granger <firstname.lastname@example.org>:
> On Mon, Jun 21, 2010 at 1:27 AM, Pierre Raybaut
> <email@example.com> wrote:
>> 2010/6/18 Brian Granger <firstname.lastname@example.org>
>>> > Since v1.1.0 (which has recently reached Release Candidate 1), IPython
>>> > has
>>> > been integrated in the external console.
>>> > See here: http://spyderlib.googlegroups.com/web/ipython.png
>>> > and there: http://spyderlib.googlegroups.com/web/spyder_light.png
>>> > That is great news (and I hope that you will be excited by these
>>> > screenshots), and following this, Spyder v2.0 should be almost
>>> > completely
>>> > based on IPython.
>>> > However, I still have some difficulties with IPython and I would really
>>> > appreciate some help to fix these bugs.
>>> > First of all, let me explain how it works. It's quite simple actually:
>>> > I'm
>>> > opening a Python interpreter in another process (QProcess) and this
>>> > interpreter executes a startup script which is here:
>>> > http://code.google.com/p/spyderlib/source/browse/spyderlib/widgets/externalshell/startup.py
>>> > Now you can see that on Windows platforms, I'm forced to do ugly things
>>> > to:
>>> > 1. fix the encoding which is not properly detected by Python in the
>>> > QProcess
>>> > (I assume that it's a Python bug on Windows) and cause errors in
>>> > pyreadline
>>> Not sure about this one.
>> Maybe I wasn't clear: this is not an IPython issue at all. This is only
>> Python itself which is unable to detect stdout encoding when you are running
>> it in a separate process on Windows (e.g. the same issue occurs in emacs
>> running a Python shell on win32).
>>> > 2. change the sys.platform to anything but 'win32' to prevent IPython
>>> > from
>>> > doing this: (in IPython.genutils):
>>> > if sys.platform == 'win32' and readline.have_readline:
>>> > Term = IOTerm(cout=readline._outputfile,cerr=readline._outputfile)
>>> When we separate IPython into two processes, this logic will be
>>> modified, so this should be taken care of.
>>> > 3. add an environment variable (to the QProcess): TERM=emacs, to prevent
>>> > IPython from using msvcrt for the 'page_more' function implementation
>>> > because like emacs, Spyder doesn't like to be bypassed with
>>> > msvcrt.getch()
>>> > (see IPython.genutils.page_more definitions)
>>> The paging functionality will need to be refactored as well.
>>> For now, I think the hacks you are doing are probably the best way to
>>> go - at least until we get the two process stuff working in ipython
>>> itself this summer.
>>> > Worse, I found a very strange bug happening when opening a PyQt file
>>> > dialog
>>> > (QFileDialog.xxx) from a mainwindow -- e.g. when using the "save figure"
>>> > feature in a matplotlib figure: the GUI window freezes and switching
>>> > back to
>>> > the IPython console and pressing Enter will unblock it! This bug only
>>> > happens in a IPython session launched into a Python interpreter running
>>> > in a
>>> > separate process (it does not happen in a simple Python interpreter
>>> > running
>>> > in a separate process).
>>> This probably has something to do with threading and event loops. You
>>> will definitely run into problems with the current designof ipython.
>>> Again, this is one of our top priorities that we are working on this
>> I really hoped that someone could think of a workaround for this one... I'm
>> quite stuck with it! :)
>> And I hope I won't have to wait until next IPython is released to fix this
>> bug: v0.10 has still not spread everywhere judging from users feedbacks.
> Unfortunately, this one will be highly non-trivial, if not
> semi-impossible with the current 0.10 design. It uses threads to
> handle the GUI event loop integration in a way that is like juggling
> with dynamite. You are using it in a way that it simply wasn't
> designed for....which is sort of like dropping the dynamite.
>>> > Any help would be really appreciated!
>>> I would join the ipython-dev list to follow along as we progress this
>>> > Thanks,
>>> > Pierre
>>> > _______________________________________________
>>> > IPython-User mailing list
>>> > IPython-User@scipy.org
>>> > http://mail.scipy.org/mailman/listinfo/ipython-user
>>> Brian E. Granger, Ph.D.
>>> Assistant Professor of Physics
>>> Cal Poly State University, San Luis Obispo
> Brian E. Granger, Ph.D.
> Assistant Professor of Physics
> Cal Poly State University, San Luis Obispo
More information about the IPython-User