Phillip J. Eby wrote:
At 06:48 PM 11/15/2005 -0500, Michiel Jan Laurens de Hoon wrote:
Thanks everybody for contributing to this discussion. I didn't expect it
to become this extensive.
I think that by now, everybody has had their chance to voice their
opinion.
It seems safe to conclude
[EMAIL PROTECTED] wrote:
Ronald ... except when the GUI you're using doesn't expose (or even
Ronald use) a file descriptor that you can use with select. Not all the
Ronald world is Linux.
Can you be more specific? Are you referring to Windows? I'm not suggesting
you'd be able to
Martin v. Löwis wrote:
Michiel Jan Laurens de Hoon wrote:
The problem with threading (apart from potential portability problems)
is that Python doesn't let us know when it's idle. This would cause
excessive repainting (I can give you an explicit example if you're
interested).
I don't
I think this is an excellent summary of the discussion so far. Probably
clearer than my own posts.
Thanks, Jim!
--Michiel.
Jim Jewett wrote:
There has been enough misunderstanding in this thread
that the summarizers are going to have trouble. So I'm
posting this draft in hopes of
Martin v. Löwis wrote:
Before trying to explain the reason, please try to explain the
problem first. What is it *really* that you want to do which
you feel you currently can't do?
Probably I should have started the discussion with this; sorry if I
confused everybody. But here it is:
I have
Martin v. Löwis wrote:
Michiel Jan Laurens de Hoon wrote:
It's not because it likes to be in charge, it's because there's no
other way to do it in Python.
As I said: this is simply not true.
You are right in the sense it is possible to get events handled using
the solutions you proposed
Martin v. Löwis wrote:
Michiel Jan Laurens de Hoon wrote:
2) Will Tkinter always be the standard toolkit for Python, or are
there plans to replace it at some point?
Python does not evolve along a grand master plan. Instead, individual
contributors propose specific modifications, e.g
Greg Ewing wrote:
I'm not sure the event-loop situation would be
much different with another one, anyway. From what
I've seen of GUI toolkits, they all have their own
form of event loop, and they all provide some way
of hooking other things into it (as does Tkinter),
but whichever one you're
Stephen J. Turnbull wrote:
Michiel What is the advantage of Tk in comparison to other GUI
Michiel toolkits?
IMO, Tk's _advantage_ is that it's there already. As a standard
component, it works well for typical simple GUI applications (thus
satisfying batteries included IMO), and it's
Dear Pythoneers,
I use Python heavily for scientific computing, originally for
computational physics and nowadays for computational biology. One of the
extension modules I support is pygist, a module for scientific
visualization. For this (and similar) packages to work, it is important
to
Below are a set of five patch reviews. I don't have any patch to push for at
this point, so these patch reviews are just for you to read and enjoy. Thanks
everybody for developing and maintaining Python. I wouldn't know what to do
without it.
--Michiel.
Patch [ 853890 ] Optional keyword
Patch review [ 1093585 ] sanity check for readline remove/replace
The functions remove_history_item and replace_history_item in the readline
module respectively remove and replace an item in the history of commands. As
outlined in bug [ 1086603 ], both functions cause a segmentation fault if the
Patch review [ 684500 ] (extending readline functionality)
This patch is a duplicate of patch [ 675551 ] (extending readline
functionality), which was first submitted against stable python version 2.2.2.
After the resubmitted patch [ 684500 ] against Python 2.3a1 was accepted
thread go idle?
--Michiel.
On Thu, Dec 09, 2004, Michiel Jan Laurens de Hoon wrote:
My suggestion is therefore to replace PyOS_InputHook by two functions
PyOS_AddInputHook and PyOS_RemoveInputHook, and let Python keep track of
which hooks are installed. This way, an extension module can add a hook
E.g. if we need to compile libpython24.a it means we need to
fetch the Python sources themselves first.
Actually, no, you don't need the sources. See:
http://mail.python.org/pipermail/python-dev/2004-January/041676.html
for a script that builds libpython24.a from the python24.lib distributed
15 matches
Mail list logo
