Echanges avec Martin Loewis concerant les évolutions de Python et Tkinter liés au wrapper python <-> ivy Date: Sun, 13 Jul 2003 18:49:35 +0200 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.4) Gecko/20030624 X-Accept-Language: de, en-us, en To: Didier PAVET Subject: Re: a request / tkinter (ENTER_TCL ENTER_PYTHON macro) In-Reply-To: <200307100715.JAA18790@basilic.dev.ath.cena.fr> Content-Type: text/plain; charset=us-ascii; format=flowed X-Seen: false X-ID: rfGYOMZcgeZyNlhDQlB5laNXLu1X06U3wOOZDJ0mi2oMCVtqUb+aQc@t-dialin.net Didier PAVET wrote: > Have you allready heard some request in that sens ? Dear Didier, Yes, this is a SourceForge feature request, see http://python.org/sf/539907 > Does it stand sensible that this patch could be integrated in Python/Tkinter > distribution and are you the right man to do that ? In some form, yes, certainly. Merely copying the macros into a header file is not sufficient though: the code has been become much more complex since 2.1, as we now also need to support multi-threaded Tcl installations. Also, in general, you cannot access C variables across different Python extension modules. Instead, you need to expose a CObject of some kind. Instead of having that C object refer to the Tcl lock, I'd rather provide access to some higher-level function pointers which can take into account the various Tcl installations. I'd encourage you to work on this for Python 2.4. Please make either Python 2.3 or the Python CVS your starting point, and please submit unified diffs to sf.net/projects/python when you are done. If you have any questions about this approach, don#t hesitate to ask. Regards, Martin Date: 10 Jul 2003 09:07:08 +0200 From: Didier PAVET To: martin@v.loewis.de Subject: a request / tkinter (ENTER_TCL ENTER_PYTHON macro) Martin, First of all, thank you for the job to maintain and upgrade python's stuff. My organisation (french R&D center for air navigation) currently benefits from python , tkinter material to build prototype, mock-up and so all. I have a request concerning _tkinter.h and _tkinter.c . In fact, in order to build a python wrapper to an in-house middleware library built in C, I have faced a problem with macro which aim at protecting interaction between tcl/tk mainloop, thread and so on . I mean these macro ; ENTER_TCL LEAVE_TCL ENTER_PYTHON LEAVE_PYTHON For the moment, these macros are private to _tkinter module and so defined in _tkinter.c. My need is to be capable from an external python module (in fact my wrapper) to use (and so to share the data) these macros. I have allready carried out a solution patching Python 2.1.3 distribution and packing my library to verify that it works . The solution is to externalize and put the macros definition in the header _tkinter.h and allow external access to lock as tcl_lock, tcl_state . 2 requests : Have you allready heard some request in that sens ? Does it stand sensible that this patch could be integrated in Python/Tkinter distribution and are you the right man to do that ? Many thanks in advance for your help; it is clear for me that a positive answer would avoid me to deliver my wrapper with a patched version of Tkinter (solution which is pretty not handy). I just attached as a tar file my version of _tkinter.h and _tkinter.c derived from Python 2.1.3 (debian woody stable version). Didier -- Didier PAVET Centre d'Etudes de La Navigation Aerienne / (Chef division ICS) Office location Phone: (33 1) 69 57 68 89 - Fax: (33 1) 69 57 68 52 B1608 b025 ou 01 69 57 68 89 ou 01 69 57 68 52 E-mail: pavet@ath.cena.fr WWW: http://www.ath.cena.fr/~pavet Note : the middleware, target of my wrapper is Ivy; have a look at http://www.tls.cena.fr/products/ivy/ or http://freshmeat.net/projects/ivy/