On 1/27/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Why not?
>
> Correct me if I'm wrong, but what I got from the OP
> was that the current method does
>
>if (is_tripped) {
> for each signal {
>if the signal has occurred, call its handler
> }
> is_tripped = 0;
>}
>
Martin v. Löwis wrote:
> Greg Ewing schrieb:
>
>>>Please
>>>try to come up with a patch (e.g. by putting a while(is_tripped) loop
>>>around the for loop).
>>
>>That isn't going to fix it.
>
> Why not?
Correct me if I'm wrong, but what I got from the OP
was that the current method does
if (i
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> wrote:
>
> [not sure what "And so it goes" means in English]
I apologise. I try to restrain myself from using excessive idiom,
but sometimes I forget. It means "That is how things are, and there
is and will be more of the same."
> I
I apologise for going off-topic, but this is an explanation of why
I said that signal handling is not reliable. The only relevance to
Python is that Python should avoid relying on signals if possible,
and try to be a little defensive if not. Signals will USUALLY do
what is expected, but not alway
Tim Peters schrieb:
>> Does that mean that they are unstable, in the sense that they may
>> change behaviour in new versions of Python?
>
> They /may/ change, but they won't (== only common sense guarantees
> they won't change ;-)).
That, of course, is true for any API. For the documented API, th
Kristján V. Jónsson schrieb:
> We have been using gc.get_objects() but it has several problems:
> 1) It returns all objects in the system.
Actually, it doesn't. It only returns objects that participate
in cyclic GC (i.e. container objects).
> 2) There is no way to frame certain operations and get
Greg Ewing schrieb:
>> Please
>> try to come up with a patch (e.g. by putting a while(is_tripped) loop
>> around the for loop).
>
> That isn't going to fix it.
Why not?
> What's needed is to somehow
> atomically test and clear is_tripped at the beginning.
How would that help? The case in quest
