Michiel Jan Laurens de Hoon wrote: > There are several other reasons why the alternative solutions that came > up in this discussion are more attractive than IPython: > 1) AFAICT, IPython is not intended to work with IDLE.
Not so far, but mostly by accident. The necessary changes are fairly easy (mainly abstracting out assumptions about being in a tty). I plan on making ipython embeddable inside any GUI (including IDLE), as there is much demand for that. > 2) I didn't get the impression that the IPython developers understand > why and how their event loop works very well (which made it hard to > respond to their posts). I am primarily interested in understanding the > problem first and then come up with a suitable mechanism for events. > Without such understanding, IPython's event loop smells too much like a > hack. I said I did get that code off the ground by stumbling in the dark, but I tried to explain to you what it does, which is pretty simple: a. You find, for each toolkit, what its timer/idle mechanism is. This requires reading a little about each toolkit's API, as they all do it slightly differently. But the principle is always the same, only the implementation details change. b. You subclass threading.Thread, as you do for all threading code. The run method of this class manages a one-entry queue where code is put for execution from stdin. c. The timer you set up with the info from (a) calls the method which executes the code object from the queue in (b), with suitable locking. That's pretty much it. Following this same idea, just this week I implemented an ipython-for-OpenGL shell. All I had to do was look up what OpenGL uses for an idle callback. > 3) IPython adds another layer on top of Python. For IPython's purpose, > that's fine. But if we're just interested in event loops, I think it is > hard to argue that another layer is absolutely necessary. So rather than > setting up an event loop in a layer on top of Python, I'd prefer to find > a solution within the context of Python itself (be it threads, an event > loop, or PyOS_InputHook). I gave you a link to a 200 line script which implements the core idea for GTK without any ipython at all. I explained that in my message. I don't know how to be more specific, ipython-independent or clear with you. > 4) Call me a sentimental fool, but I just happen to like regular Python. That's fine. I'd argue that ipython is exceptionally useful in a scientific computing workflow, but I'm obviously biased. Many others in the scientific community seem to agree with me, though, given the frequency of ipython prompts in posts to the scientific computing lists. But this is free software in a free world: use whatever you like. All I'm interested in is in clarifying a technical issue, not in evangelizing ipython; that's why I gave you a link to a non-ipython example which implements the key idea using only the standard python library. > My apologies in advance to the IPython developers if I misunderstood how > it works. No problem. But your posts so far seem to indicate you hardly read what I said, as I've had to repeat several key points over and over (the non-ipython solutions, for example). Cheers, f _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
