Re: [Python-Dev] dev FAQ updated with day-to-day svn questions
Brett Cannon wrote: >I just finished fleshing out the dev FAQ > (http://www.python.org/dev/devfaq.html) with questions covering what > someone might need to know for regular usage. If anyone thinks I > didn't cover something I should have, let me know. SVK! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
Paul Moore wrote: > On 11/9/05, Bob Ippolito <[EMAIL PROTECTED]> wrote: >> On Nov 9, 2005, at 1:48 PM, Thomas Heller wrote: >> >>> Bob Ippolito <[EMAIL PROTECTED]> writes: >>> On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote: > It's a shame that > > 1) there's no equivalent of "java -jar", i.e., "python -z > FILE.ZIP", and This should work on a few platforms: env PYTHONPATH=FILE.zip python -m some_module_in_the_zip >>> It should, yes - but it doesn't: -m doesn't work with zipimport. >> That's dumb, someone should fix that. Is there a bug filed? > > I did, a while ago. http://www.python.org/sf/1250389 Please consider looking at and commenting on PEP 328 - I got zero feedback when I wrote it, and basically assumed no-one else was bothered by the -m switch's fairly significant limitations (it went in close to the first Python 2.4 alpha release, so we wanted to keep it simple). The PEP and the associated patch currently only cover lifting the limitation against executing modules inside packages, but it should be possible to extend it to cover executing modules inside zip files as well (as you say, increasing use of eggs will only make the current limitations more annoying). That discussion should probably happen on c.l.p, though. cc' me if you start one, and I can keep on eye on it through Google (I won't have time to participate actively, unfortunately :() Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
Nick Coghlan wrote: > Please consider looking at and commenting on PEP 328 - I got zero feedback > when I wrote it, and basically assumed no-one else was bothered by the -m > switch's fairly significant limitations (it went in close to the first Python > 2.4 alpha release, so we wanted to keep it simple). Oops, that should be PEP 3*3*8. PEP 328 is something completely different. That'll teach me to post without checking the PEP number ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dev FAQ updated with day-to-day svn questions
Brett Cannon wrote: > I just finished fleshing out the dev FAQ > (http://www.python.org/dev/devfaq.html) with questions covering what > someone might need to know for regular usage. If anyone thinks I > didn't cover something I should have, let me know. Should the section "Developing on Windows" disappear now? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dev FAQ updated with day-to-day svn questions
Brett Cannon wrote: > I just finished fleshing out the dev FAQ > (http://www.python.org/dev/devfaq.html) with questions covering what > someone might need to know for regular usage. If anyone thinks I > didn't cover something I should have, let me know. For question 1.2.10, I believe you also want: [miscellany] enable-auto-props = yes so that "svn add" works properly. Question 1.4.1 should cover the use of "svn diff" instead of "cvs diff" to make the patch. On that note, we need to update the patch submission guidelines to point to SVN instead of CVS (those guidelines also still say context diffs are preferred to unified diffs, which I believe is no longer true). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
On 11/10/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Paul Moore wrote: > > On 11/9/05, Bob Ippolito <[EMAIL PROTECTED]> wrote: > >> On Nov 9, 2005, at 1:48 PM, Thomas Heller wrote: > >> > >>> Bob Ippolito <[EMAIL PROTECTED]> writes: > >>> > On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote: > > > It's a shame that > > > > 1) there's no equivalent of "java -jar", i.e., "python -z > > FILE.ZIP", and > This should work on a few platforms: > env PYTHONPATH=FILE.zip python -m some_module_in_the_zip > >>> It should, yes - but it doesn't: -m doesn't work with zipimport. > >> That's dumb, someone should fix that. Is there a bug filed? > > > > I did, a while ago. http://www.python.org/sf/1250389 > > Please consider looking at and commenting on PEP 328 - I got zero feedback > when I wrote it, and basically assumed no-one else was bothered by the -m > switch's fairly significant limitations (it went in close to the first Python > 2.4 alpha release, so we wanted to keep it simple). > > The PEP and the associated patch currently only cover lifting the limitation > against executing modules inside packages, but it should be possible to extend > it to cover executing modules inside zip files as well (as you say, increasing > use of eggs will only make the current limitations more annoying). > > That discussion should probably happen on c.l.p, though. cc' me if you start > one, and I can keep on eye on it through Google (I won't have time to > participate actively, unfortunately :() I didn't respond simply because it seemed obvious that this should go in, and I expected no debate. I assumed the only reason it didn't go into 2.4 was because the issue came up too close to the release. Teach me to assume, I guess... FWIW, I'm +1 on PEP 338. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Weak references: dereference notification
Qui, 2005-11-10 às 08:15 +0100, "Martin v. Löwis" escreveu: > Gustavo J. A. M. Carneiro wrote: > > OK, but what if it is a subclass of a builtin type, with instance > > variables? What if the PyObject is GC'ed but the ObjC object remains > > alive, and later you get a new reference to it? Do you create a new > > PyObject wrapper for it? What happened to the instance variables? > > Normally, wrappers don't have state. But if you do have state, this > is how it could work: > > 1. Make two Python objects, PyState and PyWrapper (actually, > PyState doesn't need to be a Python object) > PyState holds the instance variables, and PyWrapper just > holds a pointer to a GObject. > 2. When a Python reference to a GObject is created for the > first time, create both a PyState and a PyWrapper. Have > the GObject point to the PyState, and the PyWrapper to > the GObject. Have the PyState weakly reference the > PyWrapper. > 3. When the refcount to the PyWrapper drops to zero, discard it. > 4. When somebody asks for the data in the PyWrapper, > go to the GObject, then to the PyState, and return the > data from there. > 5. When somebody wants a reference to a GObject which already > has a PyState, check the weak reference to find out > whether there is a PyWrapper already. If yes, return it; > if not, create a new one (and weakly reference it). > 6. When the GObject is discarded, drop the PyState as well. > > This has the following properties: > 1. There are no cyclic references for wrapping GObjects. > 2. Weakly-referencing wrappers is supported; if there > are no strong Python references to the wrapper, > the wrapper goes away, and, potentially, the GObject > as well. > 3. The PyState object lives as long as the GObject. > 4. Using "is" for GObjects/PyWrappers "works": there is > at most one PyWrapper per GObject at any time. > 5. id() of a GObject may change over time, if the wrapper > becomes unreferenced and then recreated. This was my first approach, actually, in patch 4.1 in [1]. Only your property 2 above drove me to try a different approach -- the weakrefs may become invalid while the GObject may still be alive. That's a bit "surprising". Of course, if I could override weakref.ref() for GObject wrapper types, even that could be worked around... ;-) Thanks, [1] http://bugzilla.gnome.org/show_bug.cgi?id=320428 -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Weak references: dereference notification
Qui, 2005-11-10 às 13:57 +1300, Greg Ewing escreveu: > Gustavo J. A. M. Carneiro wrote: > > > OK, but what if it is a subclass of a builtin type, with instance > > variables? What if the PyObject is GC'ed but the ObjC object remains > > alive, and later you get a new reference to it? Do you create a new > > PyObject wrapper for it? What happened to the instance variables? > > Your proposed scheme appears to involve destroying and > then re-initialising the Python wrapper. Isn't that > going to wipe out any instance variables it may > have had? The object isn't really destroyed. Simply ob_refcnt drops to zero, then tp_dealloc is called, which is supposed to destroy it. But since I wrote tp_dealloc, I choose not to destroy it, and revive it by calling PyObject_Init(), which makes ob_refcnt == 1 again, among other things. > > Also, it seems to me that as soon as the refcount on > the wrapper drops to zero, any weak references to it > will be broken. Or does your resurrection code > intervene before that happens? Yes, I intervene before that happens. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
On Thu, 2005-11-10 at 00:40 -0500, Michiel Jan Laurens de Hoon wrote: > Stephen J. Turnbull wrote: > > >Michiel> What is the advantage of Tk in comparison to other GUI > >Michiel> toolkits? [...] > 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 in Python. So this is the disadvantage I see in Tkinter. [...] I'm kind of surprised no-one has mentioned Twisted in this thread. Twisted is an async-framework that I believe has support for using a variety of different event-loops, including Tkinter and wxWidgets, as well as it's own. It has been heavily re-factored many times, so if you want to see the current Python "state of the art" way of doing this, I'd be having a look at what they are doing. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
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 in Python. So this is the disadvantage I see in Tkinter. That's a non-sequitur if I ever saw one. Who gave you that idea? There is no connection. (If there's *any* reason for Python not having a standard event loop it's probably because I've never needed one.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
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 before (sorry for not responding to those earlier). But I don't believe that these are very good solutions: > You are missing multi-threading, which is the widely used > approach to doing things simultaneously in a single process. In one > thread, user interaction can occur; in another, computation. If you need > non-blocking interaction between the threads, use queues, or other > global variables. If you have other event sources, deal with them > in separate threads. 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). But there is another solution with threads: Can we let Tkinter run in a separate thread instead? > Yes, it is possible to get event loops with Tkinter. Atleast on Unix, > you can install a file handler into the Tk event loop (through > createfilehandler), which gives you callbacks whenever there is some > activity on the files. This works, but only if Tkinter is installed, and even then it will give poor performance due to the busy-loop with 20 ms sleep in between in Tkinter. Furthermore, this will not work with IDLE, because the Python thread that handles user commands never enters the Tkinter event loop, even if we import Tkinter. AFAIK, there is no easy solution to this. > Furthermore, it is possible to turn the event loop around, by doing > dooneevent explicitly. Here, the problem is that we don't know *when* to call dooneevent, so we'd have to do a busy-loop and sleep in between. >> Tkinter is a special case among GUI toolkits because it is married to >> Tcl. It doesn't just need to handle its GUI events, it also needs to >> run the Tcl interpreter in between. > > That statement is somewhat deceiving: there isn't much interpreter to > run, really. I may be wrong here, but I'd think that it would be dangerous to run Tkinter's event loop when one thread is waiting for another (as happens in IDLE). >> Which is why Tkinter needs to be in charge of the event loop. For >> other GUI toolkits, I don't see a reason why they'd need their own >> event loop. > > They need to fetch events from the operating system level, and dispatch > them to the widgets. This is a perfect task for an event loop located in Python, instead of in an extension module. I could write a prototype event loop for Python to demonstrate how this would work. Sorry if I'm sounding negative, but we've actually considered many different things to get the event loop working for our scientific visualization software, and we were never able to come up with a satisfactory scheme within the current Python framework. Other packages have run into the same problem (e.g. matplotlib, which now recommends using the interactive ipython instead of regular python; the python extension for the Rasmol protein viewer is another). --Michiel. -- Michiel de Hoon Center for Computational Biology and Bioinformatics Columbia University 1150 St Nicholas Avenue New York, NY 10032 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
At 04:33 PM 11/9/2005 -0800, Guido van Rossum wrote: >On 11/9/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > By the way, while we're on this subject, can we make the optimization > > options be part of the compile() interface? Right now the distutils has to > > actually exec another Python process whenever you want to compile > > code with > > a different optimization level than what's currently in effect, whereas if > > it could pass the desired level to compile(), this wouldn't be necessary. > >Makes sense to me; we need a patch of course. But before we can do that, it's not clear to me if it should be part of the existing "flags" argument, or whether it should be separate. Similarly, whether it's just going to be a level or an optimization bitmask in its own right might be relevant too. For the current use case, obviously, a level argument suffices, with 'None' meaning "whatever the command-line level was" for backward compatibility. And I guess we could go with that for now easily enough, I'd just like to know whether any of the AST or optimization mavens had anything they were planning in the immediate future that might affect how the API addition should be structured. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
On 11/10/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 04:33 PM 11/9/2005 -0800, Guido van Rossum wrote: > >On 11/9/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > > By the way, while we're on this subject, can we make the optimization > > > options be part of the compile() interface? Right now the distutils has > > > to > > > actually exec another Python process whenever you want to compile > > > code with > > > a different optimization level than what's currently in effect, whereas if > > > it could pass the desired level to compile(), this wouldn't be necessary. > > > >Makes sense to me; we need a patch of course. > > But before we can do that, it's not clear to me if it should be part of the > existing "flags" argument, or whether it should be separate. Similarly, > whether it's just going to be a level or an optimization bitmask in its own > right might be relevant too. > > For the current use case, obviously, a level argument suffices, with 'None' > meaning "whatever the command-line level was" for backward > compatibility. And I guess we could go with that for now easily enough, > I'd just like to know whether any of the AST or optimization mavens had > anything they were planning in the immediate future that might affect how > the API addition should be structured. I'm not a big user of this API, please design as you see fit. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
At 01:47 PM 11/10/2005 +, Donovan Baarda wrote: >Twisted is an async-framework that I believe has support for using a >variety of different event-loops, including Tkinter and wxWidgets, as >well as it's own. Technically, it just gives Tkinter a chance to run every so often; you specifically *can't* use Tkinter's event loop. Instead, you run the Twisted event loop after telling it that you'd like Tkinter to be kept in the loop, as it were. But Twisted is definitely worth looking at for this sort of thing. It's the nearest thing to a "standard Python event loop" that exists, apart from the asyncore stuff in the stdlib (which doesn't have any GUI support AFAIK). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
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 in Python. So this is the disadvantage I see in Tkinter. >> >> > >That's a non-sequitur if I ever saw one. Who gave you that idea? There is no >connection. > I have come to this conclusion after several years of maintaining a scientific plotting package and trying to set up an event loop for it. Whereas there are some solutions that more or less work, none of them work very well, and the solutions that we found tend to break. Other visualization packages are struggling with the same problem. I'm trying the best I can to explain in my other posts why I feel that Tkinter is the underlying reason, and why it would be difficult to solve. >(If there's *any* reason for Python not having a standard event loop >it's probably because I've never needed one.) > It's probably because we have gotten away with piggy-backing on Tcl's event loop for so long. --Michiel. -- Michiel de Hoon Center for Computational Biology and Bioinformatics Columbia University 1150 St Nicholas Avenue New York, NY 10032 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] (no subject)
Sokolov Yura writes: > Excuse my English No problem. You command of english probably exceeds my command of any other language. > I think, we could just segregate tokens for decimal and real float and > make them interoperable. >Most of us works with business databases - all "floats" are really > decimals, algebraic operations > should work without float inconsistency and those operations rare so > speed is not important. > But some of us use floats for speed in scientific and multimedia programs. I'm not sure why you say "most" (have you seen some surveys of Python programmers that I haven't seen?), but I think we all agree that there are Python users who rarely have a need for machine floats, and others who badly need them. I'll take your specific suggestions out of order: > with "from __future__ import Decimal" we could: > c) result of operation with decimal operands should be decimal > >>> 1.0/3.0 > 0.3 This already works. > d) result of operation with float operands should be float > >>> 1.0f/3.0f > 0.1f This already works. > e) result of operation with decimal and float should be float (decimal > converts into float and operation perfomed) > >>> 1.0f/3.0 > 0.1f > >>> 1.0/3.0f > 0.1f Mixing Decimal and float is nearly ALWAYS a user error. Doing it correctly requires significant expertise in the peculiarities of floating point representations. So Python protects the user by throwing exceptions when attempts are made to mix Decimal and floats. This is the desired behavior (and the experts already know how to work around it in the RARE occasions when they need to). > a) interpret regular float constants as decimal > b) interpret float constants with suffix 'f' as float (like1.5f > 345.2e-5f etc) There are two different ideas here, which I will separate. The first is a proposal that there be a way to provide Decimal literals. The second proposal is that the ###.### be the literal for Decimals and that ###.###f be the literal for floats. I'm in favor of the first idea. Decimals are useful enough that it would be a good idea to provide some sort of literal for their use. This is well worth a PEP. But if we DO agree that we ought to have literals for both floats and Decimals, then we also need to decide which gets the coveted "unadorned decimal literal" (ie, ###.###). Performance argues in favor of floats (they run *MUCH* faster). Usability (particularly for beginners) argues in favor of Decimals (they sometimes still have surprising behavior, but less often than with binary floats). And backward compatibility argues in favor of floats. Myself, I'm an "expert" user (at least to this extent) and I could easily handle either choice. If others felt like me, then its likely that the backward compatibility argument and the need to fight the pervasive meme that "Python is slow" will win the day. -- Michael Chermside ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Building Python with Visual C++ 2005 Express Edition
I didn't see any mention of this product in the Python-Dev list, so I thought to let you know. http://msdn.microsoft.com/vstudio/express/visualc/download/ There is also a link for a CD image (.img) file to download. I am downloading now, so I don't know yet whether Python compiles with it without any problems. So if anyone has previous experience, please reply. PS This page ( http://msdn.microsoft.com/vstudio/express/support/faq/default.aspx#pricing ) says that if you download it until Nov 7, 2006, it's a gift --the Microsoft VC++ compiler for free (perhaps a cut-down version). Bits from the FAQ: http://msdn.microsoft.com/vstudio/express/support/faq/default.aspx 4. Can be used even for commercial products without licensing restrictions 40. It includes the optimizing compiler (without stuff like Profile Guided Optimizations) 41. Builds both native and managed applications (you 99% need to download the SDK too) 42. No MFC or ATL included ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dev FAQ updated with day-to-day svn questions
On 11/10/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: > > I just finished fleshing out the dev FAQ > > (http://www.python.org/dev/devfaq.html) with questions covering what > > someone might need to know for regular usage. If anyone thinks I > > didn't cover something I should have, let me know. > > Should the section "Developing on Windows" disappear now? > Well, the whole dev doc section needs cleaning up and that includes the dev FAQ. I was planning on doing this at some point; might as well start talking about it now. In my mind, the steps in each of the major things to do (bugs and patches) needs better docs. With that fleshed out, Intro to Development can act as an overview of the process. This should, together with the dev FAQ, cover what someone needs to do dev work. The question is how to structure the bug/patch guidelines. There are two options; dev FAQ entires much like the svn section or a more classic layout of the info. Both would have a bulleted list of the steps necessary for a bug/patch. The question is whether the information is presented in paragraphs of text following the bulleted list or as a list of questions. What do people prefer? -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Michiel Jan Laurens de Hoon wrote: >>You are missing multi-threading, which is the widely used >>approach to doing things simultaneously in a single process. > > 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 understand how these are connected: why do you need to know when Python is idle for multi-threaded applications, and why does not knowing that it is idle cause massive repainting? Not sure whether an explicit example would help, though; one would probably need to understand a lot of details of your application. Giving a simplified version of the example might help (which would do 'print "Repainting"' instead of actually repainting). > 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 (separate from all other threads). > This works, but only if Tkinter is installed, and even then it will give > poor performance due to the busy-loop with 20 ms sleep in between in > Tkinter. Furthermore, this will not work with IDLE, because the Python > thread that handles user commands never enters the Tkinter event loop, > even if we import Tkinter. AFAIK, there is no easy solution to this. Here I'm losing track. What is "this" which is no easy solution for? Why do you need a callback when Python is idle in the first place? > I may be wrong here, but I'd think that it would be dangerous to run > Tkinter's event loop when one thread is waiting for another (as happens > in IDLE). I don't understand. Threads don't wait for each other. Threads wait for events (which might be generated by some other thread, of course). However, there is no problem to run the Tkinter event loop when some unnrelated thread is blocked. > Sorry if I'm sounding negative, but we've actually considered many > different things to get the event loop working for our scientific > visualization software, and we were never able to come up with a > satisfactory scheme within the current Python framework. I really don't see what the problem is. Why does the visualization framework care that Tkinter is around? Why are the events that the visualization framework needs to process? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Michiel Jan Laurens de Hoon wrote: > I have come to this conclusion after several years of maintaining a > scientific plotting package and trying to set up an event loop for > it. Whereas there are some solutions that more or less work, none of > them work very well, and the solutions that we found tend to break. > Other visualization packages are struggling with the same problem. As you can see, the problem is not familiar to anybody reading python-dev. > I'm trying the best I can to explain in my other posts why I feel > that Tkinter is the underlying reason, and why it would be difficult > to solve. 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? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dev FAQ updated with day-to-day svn questions
Nick Coghlan wrote: > Should the section "Developing on Windows" disappear now? I think so, yes (along with the document it refers to). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building Python with Visual C++ 2005 Express Edition
Christos Georgiou wrote: > I didn't see any mention of this product in the Python-Dev list, so I > thought to let you know. > > http://msdn.microsoft.com/vstudio/express/visualc/download/ > > There is also a link for a CD image (.img) file to download. > > I am downloading now, so I don't know yet whether Python compiles with it > without any problems. So if anyone has previous experience, please reply. I don't have previous experience, but I think this it likely shares the issues that VS.NET 2005 has with the current code: 1. the project files are for VS.NET 2003. In theory, conversion to the new format is supported, but I don't know whether this conversion works flawlessly. 2. MS broke ISO C conformance in VS.NET 2005 in a way that affects Python's signal handling. There is a patch on SF which addresses the issue, but that hasn't been checked in yet. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dev FAQ updated with day-to-day svn questions
On 11/10/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: > > I just finished fleshing out the dev FAQ > > (http://www.python.org/dev/devfaq.html) with questions covering what > > someone might need to know for regular usage. If anyone thinks I > > didn't cover something I should have, let me know. > > For question 1.2.10, I believe you also want: > >[miscellany] >enable-auto-props = yes > > so that "svn add" works properly. Added. Missed that I had it in my personal config. =) > > Question 1.4.1 should cover the use of "svn diff" instead of "cvs diff" to > make the patch. > Changed. > On that note, we need to update the patch submission guidelines to point to > SVN instead of CVS (those guidelines also still say context diffs are > preferred to unified diffs, which I believe is no longer true). > Fixed and fixed. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Michiel wrote: > 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 in Python. So this is the disadvantage I see in Tkinter. > >> > >> > > > >That's a non-sequitur if I ever saw one. Who gave you that idea? > There is no connection. > > > I have come to this conclusion after several years of maintaining > a scientific plotting package and trying to set up an event loop > for it. Whereas there are some solutions that more or less work, > none of them work very well, and the solutions that we found tend > to break. Other visualization packages are struggling with the > same problem. I'm trying the best I can to explain in my other > posts why I feel that Tkinter is the underlying reason, and why > it would be difficult to solve. I believe this problem all boils down to this paragraph from the first mail on this topic: : Currently, event loops are available in Python via PyOS_InputHook, a : pointer to a user-defined function that is called when Python is idle : (waiting for user input). However, an event loop using PyOS_InputHook : has some inherent limitations, so I am thinking about how to improve : event loop support in Python. Either we have an unusual definition of "event loop" (as many many other toolkits have implemented event loops without PyOS_InputHook), or the requirement is for an event loop that plays nicely with the "interactive loop" in Python.exe. Assuming the latter, I would suggest simply not trying to do that! Look at the "code" module for a way you can create your own interactive loop that plays nicely with your event loop (rather than trying to do it the other way around). Otherwise, I suggest you get very specific about what this event loop should do. From a previous mail in this thread (an exchange between you and Martin): > >> Which is why Tkinter needs to be in charge of the event loop. For > >> other GUI toolkits, I don't see a reason why they'd need their own > >> event loop. > > > > They need to fetch events from the operating system level, and dispatch > > them to the widgets. > This is a perfect task for an event loop located in Python, instead of > in an extension module. I believe the point Martin was trying to make is that we have 2 "unknown" quantities here - the "operating system" and the "widgets". Each OS delivers raw GUI events differently, and each GUI framework consumes and generates events differently. I can't see what a single event loop would look like. Even on Windows there is no single, standard "event loop" construct - MFC and VB apps both have custom message loops. Mozilla XUL applications (which are very close to being able to be written in Python ) have an event loop that could not possibly be expressed in Python - but they do expose a way to *call* their standard event loop (which is quite a different thing - you are asking to *implement* it.) > I could write a prototype event loop for Python > to demonstrate how this would work. I think that would be the best way forward - this may all simply be one big misunderstanding . The next step after that would be to find even one person who currently uses an event-loop based app, and for whom your event loop would work. Mark. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
