Re: [Python-Dev] Signals, threads, blocking C functions
On Sat, 09 Sep 2006 12:59:23 +0200, Gustavo Carneiro [EMAIL PROTECTED] wrote: On 9/9/06, Jan Kanis [EMAIL PROTECTED] wrote: However, PyGTKs problem does get solved, as long as there is _a_ thread that returns to the interpreter within some timeframe. It seems plausible that this will happen. No, it is not plausible at all. For instance, the GnomeVFS library usually has a pool of thread, not doing anything, waiting for some VFS task. It is likely that a signal will be delivered to one of these threads, which know nothing about Python, and sit idle most of the time. Regards. Well, perhaps it isn't plausible in all cases. However, it is dependant on the libraries you're using and debuggable, which broken signal handlers apparently aren't. The approach would work if you don't use libraries that block threads, and if the libraries that do, co-operate with the interpreter. Open source libraries can be made to co-operate, and if you don't have the source and a library doesn't work correctly, all bets are off anyway. But having the signal handler itself write to a pipe seems to be a cleaner solution, if it can work reliable enough for some value of 'reliable'. Jan ___ 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] Explicit Lexical Scoping (pre-PEP?)
On Thu, 06 Jul 2006 18:28:12 +0200, Phillip J. Eby [EMAIL PROTECTED] wrote: Here's the reason I think this keeps coming up, and why Guido's just use a class argument doesn't really address the actual problem that's taking place. I agree this argument is not generally applicable in every case, but why not in this specific situation? In short: in *theory*, a rebinding operator or nonlocal declaration is unnecessary. In *practice*, having one seems quite useful every time you wander down the path that leads to having to rewrite your code just because the language won't let you do that one tiny thing - I think this argument is a too general one. To me it is too close to let's add every possible feature we can find, because it might be usefull to someone :) One of the things I like about python is that it doesn't do this, and therefore the manual stays relatively small and I don't have to remember all kinds of rarely used features to make best use of the language. (I assume this is not a point of debate. repeating: Python is not Lisp ;-) ) Most of the arguments I've seen on the list are about 'how can we implement this', I'd like to see more arguments on whether this should be implemented at all. I was hoping someone would come up with a good example, so does anyone have one?? - or so it feels like to the person who's experiencing it. Have you ever been that person, or come across such a situation? O, and I don't think the inc() example is a good one. In this incrementer the function call is all about the side effects, it's even in the name 'increment'. Incrementing is useless unless you increment /something/, so this should be better implemented as a class. ___ 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] Explicit Lexical Scoping (pre-PEP?)
On Fri, 07 Jul 2006 01:25:19 +0200, Phillip J. Eby [EMAIL PROTECTED] wrote: - or so it feels like to the person who's experiencing it. Have you ever been that person, or come across such a situation? Many times. The hard thing about trying to provide use cases for this is that of course you can always find another way to write it. It's just that sometimes the nested function is a perfect solution at point in time A, and then at point in time B, a change in the program requires that the nested function mutate a bit of state, resulting in either a rewrite to do it the right way, or hacking mutable objects. Well, not an actual example, but close enough. Leaving the rest to Guido then. ___ 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
