Michael Bayer wrote:
> i just dont understand why such an important feature would have to be
> relegated to just a "recipe". i think thats a product of the notion
> that "implicit finalizers are bad, use try/finally". thats not
> really valid for things like buffers that flush and database/
On 04/05/2007 20.35, Adam Olsen wrote:
> Any attempt that keeps the entire contents of __dict__ alive is
> doomed. It's likely to contain a cycle back to the original object,
> and avoiding that is the whole point of jumping through these hoops.
Uh? If __dict__ contains a cycle back to the origi
On 24/04/2007 0.05, Guido van Rossum wrote:
>> This PEP is to change the ``if __name__ == "__main__": ...`` idiom to
>> ``if __name__ == sys.main: ...`` so that you at least have a chance
>> to execute module in a package that use relative imports.
>>
>> Ran this PEP past python-ideas. Stopped t
On Sat, 05 May 2007 13:21:59 +0200, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>On 04/05/2007 20.35, Adam Olsen wrote:
>
>> Any attempt that keeps the entire contents of __dict__ alive is
>> doomed. It's likely to contain a cycle back to the original object,
>> and avoiding that is the whole point o
On May 5, 2007, at 6:12 AM, Nick Coghlan wrote:
>
> The reason for initially pursuing a recipe approach for weakref
> based finalisation is that it allows time to determine whether or
> not there are better recipes than whatever is proposed in the PEP
> before casting it in the form of fixe
hi all
i have to admit i've been neglecting the list in the past few months,
and i don't know whether the issue i want to bring up has been
settled already.
as you all may have noticed, multicore processors are becoming
more and more common in all kinds of machines, from desktops
to servers, and
On 5/5/07, tomer filiba <[EMAIL PROTECTED]> wrote:
> the only way to overcome this with cpython is to Kill The GIL (TM),
> and since it's a very big architectural change, it ought to happen
> soon. pushing it further than version 3.0 means all library authors
> would have to adapt their code twice
Giovanni Bajo wrote:
> Uh? If __dict__ contains a cycle back to the original object, then the object
> is part of a cycle already, with or without getting an additional reference
> to
> the __dict__ within the finalization callback.
Yes, but storing a finalizer in a global registry that
refere
Giovanni Bajo wrote:
> class Holder:
>def __init__(self):
> self.resource =
> self.__wr = weakref(self.resource, )
>
> So, are you
> saying that it's possible that the weakreference refcount goes to zero
> *before* Holder's refcount?
No, but depending on the order in w
tomer filiba wrote:
> the only way to overcome this with cpython is to Kill The GIL (TM),
> and since it's a very big architectural change, it ought to happen
> soon. pushing it further than version 3.0 means all library authors
> would have to adapt their code twice (once to make it compatible
> w
"tomer filiba" <[EMAIL PROTECTED]> wrote:
> the only way to overcome this with cpython is to Kill The GIL (TM),
> and since it's a very big architectural change, it ought to happen
> soon. pushing it further than version 3.0 means all library authors
> would have to adapt their code twice (once to
11 matches
Mail list logo
