Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Michiel Jan Laurens de Hoon wrote: > If, however, Python contains an event loop that takes care of events as > well as Python commands, redrawing won't happen until Python has > executed all plot commands -- so no repainting in vain here. Ah, I think now I understand the problem. It seems that you don't care at all about event loops. What you really want to know is "when is Python idle?", by "being idle" defines as "there are no commands being processed at the interactive interpreter", or perhaps "there are no commands being processed in the main thread", or perhaps "there are no commands being processed in any thread". Is that a correct problem statement? If so, please don't say that you want an event loop. Instead, it appears that you want to hook into the interpreter loop. As others have commented, it should be possible to get nearly the same effect without such hooking. For example, if you chose to redraw at most 10 times per second, you will still get good performance. Alternatively, you could chose to redraw if there was no drawing command for 100ms. Regards, Martin ___ 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
Re: [Python-Dev] str.dedent
On Sunday 2005-11-13 17:43, Marc-Andre Lemburg wrote: [Noam Raphael:] > > The idea is to add a method called "dedent" to strings. It would do > > exactly what the current textwrap.indent function does. [Marc-Andre:] > You are missing a point here: string methods were introduced > to make switching from plain 8-bit strings to Unicode easier. > > As such they are only needed in cases where an algorithm > has to work on the resp. internals differently or where direct > access to the internals makes a huge difference in terms > of performance. In a language that generally pays as much attention to practical usability as Python, it seems a pity to say (as you seem to be implying) that whether something is a string method or a function in (say) the "textwrap" module should be determined by internal implementation details. > > Writing multilined strings without spaces in the beginning of lines > > makes functions harder to read, since although the Python parser is > > happy with it, it breaks the visual indentation. > > This is really a minor compiler/parser issue and not one which > warrants adding another string method. Adding another string method seems easier, and a smaller change, than altering the compiler or parser. What's your point here? I think I must be missing something. -- g ___ 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
Re: [Python-Dev] str.dedent
Gareth McCaughan wrote: > On Sunday 2005-11-13 17:43, Marc-Andre Lemburg wrote: > > [Noam Raphael:] > >>>The idea is to add a method called "dedent" to strings. It would do >>>exactly what the current textwrap.indent function does. > > > [Marc-Andre:] > >>You are missing a point here: string methods were introduced >>to make switching from plain 8-bit strings to Unicode easier. >> >>As such they are only needed in cases where an algorithm >>has to work on the resp. internals differently or where direct >>access to the internals makes a huge difference in terms >>of performance. > > > In a language that generally pays as much attention to > practical usability as Python, it seems a pity to say > (as you seem to be implying) that whether something is > a string method or a function in (say) the "textwrap" > module should be determined by internal implementation > details. We have to draw a line somewhere - otherwise you could just as well add all functions that accept single string arguments as methods to the basestring sub-classes. >>>Writing multilined strings without spaces in the beginning of lines >>>makes functions harder to read, since although the Python parser is >>>happy with it, it breaks the visual indentation. >> >>This is really a minor compiler/parser issue and not one which >>warrants adding another string method. > > Adding another string method seems easier, and a smaller > change, than altering the compiler or parser. What's your > point here? I think I must be missing something. The point is that the presented use case does not originate in a common need (to dedent strings), but from a desire to write Python code with embedded indented triple-quoted strings which lies in the scope of the parser, not that of string objects. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 14 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2005-10-17: Released mxODBC.Zope.DA 1.0.9http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
On 11/14/05, Ulrich Berning <[EMAIL PROTECTED]> wrote: > >You seem to forget the realities of backwards compatibility. While > >there are ways to cache bytecode without having multiple extensions, > >we probably can't do that until Python 3.0. > > > Please can you explain what backwards compatibility means in this > context? Generated bytecode is neither upwards nor backwards compatible. No, but the general format of .pyc/.pyo files hasn't changed since 1991 (magic number, timestamp, marshalled data) and while the magic number has changed many times, the API for getting it has been stable for probably 10 years. Lots of tools (you mention a few) have been written that read or write these files and these would all to some extent have to be taught by the changes (most likely the changes will include a change to the file header). > No matter what I try, I always get a 'Bad magic number' when I try to > import bytecode generated with a different Python version. > The most obvious software, that may depend on the existence of .pyo > files are the various freeze/packaging tools like py2exe, py2app, > cx_Freeze and Installer. I haven't checked them in detail, but after a > short inspection, they seem to be independent of the existence of .pyo > files. I can't imagine that there is any other Python software, that > depends on the existence of .pyo files, but maybe I'm totally wrong in > this wild guess. It's not just the existence of .pyo files. It's the format of the .pyc files that will have to change to accommodate multiple versions of bytecode. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
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 use the same exact implementation on Unix and non-Unix platforms. You might well have to do different things across different platforms. Hopefully it would look the same to the programmer though, both across platforms and across toolkits. I can't imagine any of the X-based widget toolkits on Unix systems would use anything other than select() on a socket at the bottom. Skip ___ 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
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
Mark Hammond schrieb: >>release. The main reason why I changed the import behavior was >>pythonservice.exe from the win32 extensions. pythonservice.exe imports >>the module that contains the service class, but because >>pythonservice.exe doesn't run in optimized mode, it will only import a >>.py or a .pyc file, not a .pyo file. Because we always generate bytecode >>with -OO at distribution time, we either had to change the behavior of >>pythonservice.exe or change the import behavior of Python. >> >> > >While ignoring the question of how Python should in the future handle >optimizations, I think it safe to state that that pythonservice.exe should >have the same basic functionality and operation in this regard as python.exe >does. It doesn't sound too difficult to modify pythonservice to accept -O >flags, and to modify the service installation process to allow this flag to >be specified. I'd certainly welcome any such patches. > >Although getting off-topic for this list, note that for recent pywin32 >releases, it is possible to host a service using python.exe directly, and >this is the technique py2exe uses to host service executables. It would >take a little more work to set things up to work like that, but that's >probably not too unreasonable for a custom application with specialized >distribution requirements. Using python.exe obviously means you get full >access to the command-line facilities it provides. > > Although off-topic for this list, I should give a reply. I have done both. My first approach was to change pythonservice.exe to accept -O and -OO and set the Py_OptimizeFlag accordingly. Today, we aren't using pythonservice.exe any longer. I have done nearly all the required changes in win32serviceutil.py to let python.exe host the services. It requires no changes to the services, everything should work as before. The difference is, that the service module is always executed as a script now. This requires an additional (first) argument '--as-service' when the script runs as a service. NOTE: Debugging services doesn't work yet. --- Installing the service C:\svc\testService.py is done the usual way: C:\svc>C:\Python23\python.exe testService.py install The resulting ImagePath value in the registry is then: "C:\Python23\python.exe" C:\svc\testService.py --as-service After finishing development and testing, we convert the script into an executable with our own tool sib.py: C:\svc>C:\Python23\python.exe C:\Python23\sib.py -n testService -d . testService.py C:\svc>nmake Now, we just do: C:\svc>testService.exe update The resulting ImagePath value in the registry is then changed to: "C:\testService.exe" --as-service Starting, stopping and removing works as usual: C:\svc>testService.exe start C:\svc>testService.exe stop C:\svc>testService.exe remove --- Because not everything works as before (debugging doesn't work, but we do not use it), I haven't provided a patch yet. As soon as I have completed it, I will have a patch available. Ulli ___ 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
[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 use the same exact implementation on Unix and non-Unix >platforms. You might well have to do different things across different >platforms. Hopefully it would look the same to the programmer though, both >across platforms and across toolkits. I can't imagine any of the X-based >widget toolkits on Unix systems would use anything other than select() on a >socket at the bottom. > >Skip > > As far as I know, that is correct (except that some systems use poll instead of select). For our extension module, we use select or poll to wait for events on Unix (using X). I have not run into problems with this on the Unix systems I have used, nor have I received complaints from users that this didn't work. On Windows, the situation is even easier. MsgWaitForMultipleObjects can wait for events on all windows created by the thread as well as stdin (the same function is used in Tcl's event loop). In contrast to Unix' select, we don't need to tell MsgWaitForMultipleObjects which callback function is associated with each window. --Michiel. -- Michiel de Hoon Center for Computational Biology and Bioinformatics Columbia University 1150 St Nicholas Avenue New York, NY 10032 ___ 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Michiel Jan Laurens de Hoon wrote: > >Did you read my reply? ipython, based on code.py, implements a few simple > >threading tricks (they _are_ simple, since I know next to nothing about > >threading) and gives you interactive use of PyGTK, WXPython and PyQt > >applications in a manner similar to Tkinter. > > > That may be, and I think that's a good thing, but it's not up to me to > decide if PyGtk should support interactive use. The PyGtk developers > decide whether they want to decide to spend time on that, and they may > decide not to, no matter how simple it may be. can you *please* start reading the posts you're replying to? ___ 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Michiel Jan Laurens de Hoon wrote: > This is exactly the problem. Drawing one picture may consist of many > Python commands to draw the individual elements (for example, several > graphs overlaying each other). We don't know where in the window each > element will end up until we have the list of elements complete. For > example, the axis may change (see my example to Martin). Or, if we're > drawing a 3D picture, then one element may obscure another. > > Now, if we have our plotting extension module in a separate thread, the > window will be repainted each time a new element is added. Imagine a > picture of 1000 elements: we'd have to draw 1+2+...+1000 times. > > So this is tricky: we want repainting to start as soon as possible, but > not sooner. Being able to hook into Python's event loop allows us to do so. the solution to your problem is called damage/repair, is not tricky at all, and is supported by every GUI toolkit under the sun. (if you don't know how it works, google for "widget damage repair") ___ 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
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
Guido van Rossum schrieb: >On 11/11/05, Ulrich Berning <[EMAIL PROTECTED]> wrote: > > >>For instance, nobody would give the output of a C compiler a different >>extension when different compiler flags are used. >> >> > >But the usage is completely different. With C you explicitly manage >when compilation happens. With Python you don't. When you first run >your program with -O but it crashes, and then you run it again without >-O to enable assertions, you would be very unhappy if the bytecode >cached in a .pyo file would be reused! > > > The other way round makes definitely more sense. At development time, I would never use Python with -O or -OO. I use it only at distribution time, after doing all the tests, to generate optimized bytecode. However, this problem could be easily solved, if the value of Py_OptimizeFlag would be stored together with the generated bytecode. At import time, the cached bytecode would not be reused if the current value of Py_OptimizeFlag doesn't match the stored value (if the .py file isn't there any longer, we could either raise an exception or we could emit a warning and reuse the bytecode anyway). And if we do this a little bit more clever, we could refuse reusing optimized bytecode if we are running without -O or -OO and ignore assertions and docstrings in unoptimized bytecode when we are running with -O or -OO. >>I would appreciate to see the generation of .pyo files completely >>removed in the next release. >> >> > >You seem to forget the realities of backwards compatibility. While >there are ways to cache bytecode without having multiple extensions, >we probably can't do that until Python 3.0. > > > Please can you explain what backwards compatibility means in this context? Generated bytecode is neither upwards nor backwards compatible. No matter what I try, I always get a 'Bad magic number' when I try to import bytecode generated with a different Python version. The most obvious software, that may depend on the existence of .pyo files are the various freeze/packaging tools like py2exe, py2app, cx_Freeze and Installer. I haven't checked them in detail, but after a short inspection, they seem to be independent of the existence of .pyo files. I can't imagine that there is any other Python software, that depends on the existence of .pyo files, but maybe I'm totally wrong in this wild guess. Ulli ___ 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
On 14-nov-2005, at 16:00, [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 was thinking of MacOS X. It does have a eventloop, but doesn't expose a file descriptor to the user and might not even use one. Adding Python's input to the runloop of the GUI might be easier (e.g. feed the stdin filedescriptor to the GUI-toolkit-du-jour and process information when that runloop tells you that data is present). We have an example of that in the PyObjC source tree. I'd say either choice won't be very good. The problem is that you must interleave the execution of Python code with running the eventloop to get nice behaviour, which suggests threading to me. If you don't interleave you can easily block the GUI while Python code is executing. > I'm not suggesting > you'd be able to use the same exact implementation on Unix and non- > Unix > platforms. You might well have to do different things across > different > platforms. Hopefully it would look the same to the programmer > though, both > across platforms and across toolkits. Twisted anyone? ;-) ;-) > I can't imagine any of the X-based > widget toolkits on Unix systems would use anything other than select > () on a > socket at the bottom. I'd be very surprised if an X-based toolkit didn't use a select-loop somewhere. Ronald > > Skip ___ 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
On 14-nov-2005, at 8:16, Josiah Carlson wrote: > > I personally like Edward Loper's idea of just running your own event > handler which deals with drawing, suspend/resume, etc... > >> If, however, Python contains an event loop that takes care of >> events as >> well as Python commands, redrawing won't happen until Python has >> executed all plot commands -- so no repainting in vain here. > > ...but even without posting and reading events as stated above, one > could check for plot events every 1/100th a second. If there is an > update, and it has been 10/100 seconds since that undrawn event > happened, > redraw. Tune that 10 up/down to alter responsiveness characteristics. > > Or heck, if you are really lazy, people can use a plot() calls, but > until an update_plot() is called, the plot isn't updated. 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. Ronald > > There are many reasonable solutions to your problem, not all of which > involve changing Python's event loop. > > - Josiah > > ___ > 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/ > ronaldoussoren%40mac.com ___ 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
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 are two remaining issues though: 1) Currently, there's only one PyOS_InputHook. So we're stuck if we find that some other extension module already set PyOS_InputHook. An easy solution would be to have an PyOS_AddInputHook/PyOS_RemoveInputHook API, and let Python maintain a list of input hooks to be called. 2) All extension modules have to agree to return immediately from a call to the hook function. Tkinter currently does not do this. --Michiel. -- Michiel de Hoon Center for Computational Biology and Bioinformatics Columbia University 1150 St Nicholas Avenue New York, NY 10032 ___ 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
Re: [Python-Dev] str.dedent
On 11/14/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > We have to draw a line somewhere - otherwise you could > just as well add all functions that accept single > string arguments as methods to the basestring > sub-classes. Please read my first post in this thread - I think there's more reason for 'dedent' to be a string method than there is, for example, for 'expandtabs', since it allows you to write clearer code. > > The point is that the presented use case does not > originate in a common need (to dedent strings), but > from a desire to write Python code with embedded > indented triple-quoted strings which lies in the scope > of the parser, not that of string objects. > That's a theoretical argument. In practice, if you do it in the parser, you have two options: 1. Automatically dedent all strings. 2. Add a 'd' or some other letter before the string. Option 1 breaks backwards compatibility, and makes the parser do unexpected things. Option 2 adds another string-prefix letter, which is confusing, and it will also be hard to find out what that letter means. On the other hand, adding ".dedent()" at the end is very clear, and is just as easy. Now, about performance, please see the message I'll post in a few minutes... Noam ___ 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
Re: [Python-Dev] str.dedent
Just two additional notes: On 9/15/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > -1 > > Let it continue to live in textwrap where the existing pure python code > adequately serves all string-like objects. It's not worth losing the > duck typing by attaching new methods to str, unicode, UserString, and > everything else aspiring to be string-like. It may seem like the 'dedent' code would have to be written a lot of times, but I've checked the examples. It may be needed to write different versions for 'str' and for 'unicode', but these are going to be unified. In UserString you'll have to add exactly one line: def dedent(self): return self.data.dedent() I've just taken the line created for 'isalpha' and replaced 'isalpha' with 'dedent'. So in the long run, there will be exactly one implementation of 'dedent' in the Python code. (I don't know of any other objects which try to provide the full string interface.) Another reason for prefering a 'dedent' method over a 'dedent' function in some module, is that it allows sometime in the future to add an optimization to the compiler, so that it will dedent the string in compile time (this can't work for a function, since the function is found in run time). This will solve the performance problem completely, so that there will be an easy way to write multilined strings which do not interfere with the visual structure of the code, without the need to worry about performance. I'm not saying that this optimization has to be done now, just that 'dedent' as a method makes it possible, which adds to the other arguments for making it a method. Noam ___ 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
On Sun, Nov 13, 2005, Josiah Carlson wrote: > > I personally like Edward Loper's idea of just running your own event > handler which deals with drawing, suspend/resume, etc... > >> If, however, Python contains an event loop that takes care of events as >> well as Python commands, redrawing won't happen until Python has >> executed all plot commands -- so no repainting in vain here. > > ...but even without posting and reading events as stated above, one > could check for plot events every 1/100th a second. If there is an > update, and it has been 10/100 seconds since that undrawn event happened, > redraw. Tune that 10 up/down to alter responsiveness characteristics. ...and that's exactly what my sample threaded GUI application does. Can we please move this thread to comp.lang.python? -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair ___ 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Michiel> 1) Currently, there's only one PyOS_InputHook. So we're stuck Michiel>if we find that some other extension module already set Michiel>PyOS_InputHook. An easy solution would be to have an Michiel>PyOS_AddInputHook/PyOS_RemoveInputHook API, and let Python Michiel>maintain a list of input hooks to be called. I think we've come more-or-less full circle to the point where I jumped onto this spinning thread. If there is only a single input hook function, you probably need to write a slightly higher level module that manages the hook. See sys.exitfunc and the atexit module for a simple example. Skip ___ 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
Re: [Python-Dev] str.dedent
Noam Raphael wrote: > That's a theoretical argument. In practice, if you do it in the > parser, you have two options: > > 1. Automatically dedent all strings. > 2. Add a 'd' or some other letter before the string. > > Option 1 breaks backwards compatibility, and makes the parser do > unexpected things. Option 2 adds another string-prefix letter, which > is confusing, and it will also be hard to find out what that letter > means. On the other hand, adding ".dedent()" at the end is very clear, > and is just as easy. so is putting the string constant in a global variable, outside the scope you're in, like you'd do with any other constant. (how about a new rule: you cannot post to a zombie thread on python- dev unless they've fixed/reviewed/applied or otherwise processed at least one tracker item earlier the same day. there are hundreds of items on the bugs and patches trackers that could need some loving care) ___ 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
On 11/14/05, Michiel Jan Laurens de Hoon <[EMAIL PROTECTED]> wrote: > 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. No. It is definitely a bad solution. Where I work, we do a lot of plotting from the interactive interpreter, using Tkinter. I always wondered how it worked, and assumed that it was done using threading. So when people started using IDLE, and those plots didn't show up, I've found the solution of calling the Tkinter main() function from a thread. Everything seemed to work fine, until... It didn't. Strange freezes started to appear, only when working from IDLE. This made me investigate a bit, and I've found that Tkinter isn't run from a seperate thread - the dooneevent() function is called repeatedly by PyOS_InputHook while the interpreter is idle. The conclusions: 1. Don't use threads when you don't have to. Tkinter does callbacks to Python code, and most code isn't designed to work reliably in multithreaded environment. 2. The non-threading solution works *really* well - the fact is that I hadn't noticed the difference between multi-threaded mode and single-threaded mode, until things began to freeze in the multi-threaded mode. Noam ___ 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
Re: [Python-Dev] str.dedent
On 11/14/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > so is putting the string constant in a global variable, outside the scope > you're in, like you'd do with any other constant. Usually when I use a constant a single time, I write it where I use it, and don't give it a name. I don't do: messagea = "The value of A is " ... (a long class definition) print messagea, A This is what I mean when I say "constant" - a value which is known when I write the code, not necessarily an arbitrary value that may change, so I write it at the beginning of the program for others to know it's there. There's no reason why multilined strings that are used only once should be defined at the beginning of a program (think about a simple CGI script, which prints HTML parts in a function.) > > (how about a new rule: you cannot post to a zombie thread on python- > dev unless they've fixed/reviewed/applied or otherwise processed at least > one tracker item earlier the same day. there are hundreds of items on the > bugs and patches trackers that could need some loving care) > I posted to this thread because it was relevant to a new post about dedenting strings. Anyway, I looked at bug 1356720 (Ctrl+C for copy does not work when caps-lock is on), and posted there a very simple patch which will most probably solve the problem. I also looked at bug 1337987 (IDLE, F5 and wrong external file content. (on error!)). One problem it raises is that IDLE doesn't have a "revert" command and that it doesn't notice if the file was changed outside of IDLE. I am planning to fix it. The other problem that is reported in that bug is that exceptions show misleading code lines when the source file was changed but wasn't loaded into Python. Perhaps in compiled code, not only the file name should be written but also its modification time? This way, when tracebacks print lines of changed files, they can warn if the line might not be the right line. Noam ___ 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Noam Raphael wrote: > It didn't. Strange freezes started to appear, only when working from > IDLE. This made me investigate a bit, and I've found that Tkinter > isn't run from a seperate thread - the dooneevent() function is called > repeatedly by PyOS_InputHook while the interpreter is idle. repeatedly? The standard myreadline implementation only calls the hook *once* for each line it reads from stdin: if (PyOS_InputHook != NULL) (void)(PyOS_InputHook)(); errno = 0; p = fgets(buf, len, fp); if (p != NULL) return 0; /* No error */ which isn't enough to keep any event pump going... If you want any other behaviour, you need GNU readline, or a GUI toolkit that takes control over the InputHook, just like Tkinter. And that won't help you if you want portable code; for example, Tkinter on Windows only keeps the event pump running as long as the user doesn't type anything. As soon as the user touches the keyboard, the pump stops. To see this in action, try this: >>> from Tkinter import * >>> label = Label(text="hello") >>> label.pack() and then type >>> label.after(1000, lambda: label.config(bg="red")) and press return. The widget updates after a second. Next, type >>> label.after(1000, lambda: label.config(bg="blue")) press return, and immediately press space. This time, nothing happens, until you press return again. If you want to write portable code that keeps things running "in the background" while the users hack away at the standard interactive prompt, InputHook won't help you. ___ 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
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
On 11/15/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > If you want to write portable code that keeps things running "in the > background" while the users hack away at the standard interactive > prompt, InputHook won't help you. > So probably it should be improved, or changed a bit, to work also on Windows. Or perhaps it's Tkinter. Anyway, what I'm saying is - don't use threads! Process events in the main thread while it doesn't run the user's Python code. If he runs another thread - that's his problem. The implicit event loop should never execute Python code while a user's Python code is running in the main thread. Noam ___ 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
[Python-Dev] Coroutines (PEP 342)
I just finished reading PEP 342, and it appears to follow Hoare's Communicating Sequential Processes (CSP) where a process is a coroutine, and the communicaion is via yield and send(). It seems that if you follow that form (and you don't seem forced to, pythonically), then synchronization is not an issue. What is not clear to me, and is not discussed in the PEP, is whether coroutines can be distributed among multiple processors. If that is or isn't possible I think it should be explained in the PEP, and I'd be interested in know about it here (and ideally why it would or wouldn't work). Thanks. Bruce Eckel ___ 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
Re: [Python-Dev] str.dedent
Noam Raphael wrote: > There's no reason why multilined strings that are used only once > should be defined at the beginning of a program (think about a simple > CGI script, which prints HTML parts in a function.) I find that simple CGI scripts are precisely the example *for* putting multi-line string literals at the beginning of a file. There are multiple styles for writing such things: 1. Put headers and trailers into separate strings. This tends to become tedious to maintain, since you always have to find the matching string (e.g. if you add an opening tag in the header, you have to put the closing tag in the trailer). 2. Use interpolation (e.g. % substitution), and put the strings into the code. This works fine for single line strings. For multi-line strings, the HTML code tends to clutter the view of the algorithm, whether it is indented or not. Functions should fit on a single screen of text, and adding multiline text into functions tends to break this requirement. 3. Use interpolation, and put the templates at the beginning. This makes the templates easy to inspect, and makes it easy to follow the code later in the file. It is the style I use and recommend. Of course, it may occasionally become necessary to have a few-lines string literally in a function; in most cases, indenting it along with the rest of the function is fine, as HTML can stand extra spaces with no problems. Regards, Martin ___ 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
Re: [Python-Dev] str.dedent
James Y Knight wrote: > ITYM you mean "If only python were lisp". (macros, or even reader macros) No, I mean it would be more satisfying if there were a syntax for expressing multiline string literals that didn't force it to be at the left margin. The lack of such in such an otherwise indentation-savvy language seems a wart. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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
Re: [Python-Dev] Coroutines (PEP 342)
At 03:46 PM 11/14/2005 -0700, Bruce Eckel wrote: >I just finished reading PEP 342, and it appears to follow Hoare's >Communicating Sequential Processes (CSP) where a process is a >coroutine, and the communicaion is via yield and send(). It seems that >if you follow that form (and you don't seem forced to, pythonically), >then synchronization is not an issue. > >What is not clear to me, and is not discussed in the PEP, is whether >coroutines can be distributed among multiple processors. If you were to write a trampoline that used multiple threads, *and* you were using a Python implementation that supported multiple processors (e.g. Jython, IronPython, ?), *and* that Python implementation supported PEP 342, then yes. However, that just means the answer is, "if you can run Python code on multiple processors, you can run Python code on multiple processors". PEP 342 itself has nothing to say about that issue, which exists independently of the PEP. So, the PEP doesn't address what you're asking about, because the GIL still exists in CPython, and will continue to exist. Also, guaranteeing encapsulation of the coroutines would be *hard*, because lots of Python objects like modules, functions, and the like would be shared between more than one coroutine, and so then the issue of locking raises its ugly head again. > If that is or >isn't possible I think it should be explained in the PEP, and I'd be >interested in know about it here (and ideally why it would or wouldn't >work). The PEP is entirely unrelated (and entirely orthogonal) to whether a given Python implementation can interpret Python code on multiple processors simultaneously. The only difference between what PEP 342 does and what Twisted does today is in syntax. PEP 342 just provides a syntax that lets you avoid writing your code in CPS (continuation-passing style) with lots of callbacks. PEP 342 is implemented in the current Python SVN HEAD, by the way, if you want to experiment with the implementation. ___ 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
