On Saturday 02 September 2006 23:58, Anthony Baxter wrote:
> I think this is suitable for 2.5. I'm thinking, though, that we need a
> second release candidate, given the number of changes since rc1.
+1
-Fred
--
Fred L. Drake, Jr.
___
Python-De
On Sun, Sep 03, 2006, Anthony Baxter wrote:
>
> I think this is suitable for 2.5. I'm thinking, though, that we need
> a second release candidate, given the number of changes since rc1.
+1
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
I support the RKAB
On Sunday 03 September 2006 03:11, Raymond Hettinger wrote:
> [Neal]
>
> > Please review the patch and make a comment. I did a diff between HEAD
> > and 2.4 and am fine with this going in once you are happy.
>
> I fixed a couple of documentation nits in rev 51688.
> The patch is ready-to-go.
> Nic
"Gustavo Carneiro" <[EMAIL PROTECTED]> wrote:
>
> Oh, sorry, here's the comment:
>
> (coment by Arjan van de Ven):
> | afaik the kernel only sends signals to threads that don't have them blocked.
> | If python doesn't want anyone but the main thread to get signals, it
> should just
> | block si
[Neal]
> Please review the patch and make a comment. I did a diff between HEAD
> and 2.4 and am fine with this going in once you are happy.
I fixed a couple of documentation nits in rev 51688.
The patch is ready-to-go.
Nick, please go ahead and backport.
Raymond
___
On 9/2/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> According to [1], all python needs to do to avoid this problem is
> block all signals in all but the main thread; then we can guarantee
> signal handlers are always called from the main thread, and pygtk
> doesn't need a timeout.
1) That page
The "x86 XP trunk" build slave will be down for a bit longer,
unfortunately. Tropical storm Ernesto got in the way of my DSL
installation - I don't have a new install date yet, but I'm assuming
it's going to be Tuesday or later.
Alan
___
Python-Dev mail
John J Lee wrote:
> On Thu, 31 Aug 2006, Nick Coghlan wrote:
> [...]
>> I committed this fix as 51664 on the trunk (although the docstrings are still
>> example free because doctest doesn't understand __future__ statements).
> [...]
>
> Assuming doctest doesn't try to parse the Python code when SK
On Thu, 31 Aug 2006, Nick Coghlan wrote:
[...]
> I committed this fix as 51664 on the trunk (although the docstrings are still
> example free because doctest doesn't understand __future__ statements).
[...]
Assuming doctest doesn't try to parse the Python code when SKIP is
specified, I guess this
"Gustavo Carneiro" <[EMAIL PROTECTED]> wrote:
>
> We have to resort to timeouts in pygtk in order to catch unix signals
> in threaded mode.
A common defect of modern designs - TCP/IP is particularly objectionable
in this respect, but that battle was lost and won over two decades ago :-(
> The re
We have to resort to timeouts in pygtk in order to catch unix signals
in threaded mode.
The reason is this. We call gtk_main() (mainloop function) which
blocks forever. Suppose there are threads in the program; then any
thread can receive a signal (e.g. SIGINT). Python catches the signal,
but do
11 matches
Mail list logo
