PyOS_InputHook is a pointer to a function that is called periodically (ten
times per second) while Python is idle, for example, when waiting for a
user command. Python C extension modules can set this pointer to a hook
function defined in the extension module. For example, _tkinter.c makes
use of P
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
wit
Jack Jansen wrote:
Also, could you point me to a readily available extension package that
uses c++?
The Bio.Affy and Bio.KDTree extensions in Biopython use c++. See
www.biopython.org.
--Michiel.
--
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome
does the second 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
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
(Modules/readline.c
Patch review [ 723201 ] PyArg_ParseTuple problem with 'L' format
The PyArg_ParseTuple function (PyObject *args, char *format, ...) parses the
arguments args and stores them in the variables specified following the format
argument. If format=="i", indicating an integer, but the corresponding Python
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
it
Patch review [ 981773 ] crach link c++ extension by mingw
When building a C++ extension for Windows using MinGW, the linking would fail
due to an incorrect link command. The patch contains a solution for this problem.
I could reproduce this bug with Python 2.3.5c1, but in Python 2.4 it seems to
This is my last patch review in a series of five; next time I'll send them in a
bunch of five as requested. I reviewed the following patches:
[ 684500 ] extending readline functionality
[ 723201 ] PyArg_ParseTuple problem with 'L' format
[ 981773 ] crach link c++ extension by mingw
[ 985713 ] bug
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 unicode
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 have
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
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
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
Guido van Rossum wrote:
>On 11/9/05, Michiel Jan Laurens de Hoon <[EMAIL PROTECTED]> wrote:
>
>
>>My application doesn't need a toolkit at all. My problem is that because
>>of Tkinter being the standard Python toolkit, we cannot have a decent
>>event loop
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 clarificat
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 h
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 exp
Greg Ewing wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>
>>I have an extension module for scientific visualization. This extension
>>module opens one or more windows, in which plots can be made.
>>
>>
>
>What sort of windows are these? Are you usi
[EMAIL PROTECTED] wrote:
>If I have a Gtk app I have to feed other (socket, callback) pairs to it. It
>takes care of adding it to the select() call. Python could dictate that the
>way to play ball is for other packages (Tkinter, PyGtk, wxPython, etc) to
>feed Python the (socket, callback) pair.
Noam Raphael wrote:
>On 11/13/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
>
>>Noam Raphael wrote:
>>
>>
>>>All that is needed to make Tkinter and Michiels'
>>>code run together is a way to say "add this callback to the input
>>>hook" instead of the current "replace the current input hook wit
Martin v. Löwis wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>
>>But there is another solution with threads: Can we let Tkinter run in a
>>separate thread instead?
>>
>>
>
>Yes, you can. Actually, Tkinter *always* runs in a separate thread
>(separ
Greg Ewing wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>
>>Greg Ewing wrote:
>>
>>
>>>How about running your event loop in a separate thread?
>>>
>>>
>>I agree that this works for some extension modules, but not very well
Fernando Perez wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>
>>For an extension module such as
>>PyGtk, the developers may decide that PyGtk is likely to be run in
>>non-interactive mode only, for which the PyGtk mainloop is sufficient.
>>
>>
>
[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 ab
Ronald Oussoren wrote:
> I wonder why nobody has suggested a seperate thread for managing the
> GUI and
> using the hook in Python's event loop to issue the call to update_plot.
>
Ha. That's probably the best solution I've heard so far, short of adding
a Tcl-like event loop API to Python.
There
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 that there is no consensus on this topic.
So what I'm planning to do is to write a small extensi
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
29 matches
Mail list logo
