The following comments got me thinking:
Raymond:
> Statistics incontrovertibly prove that people who habitually
> avoid __del__ lead happier lives and spend fewer hours in therapy ;-)
Adam Olsen:
> I agree here. I think an executor approach is much better; kill the
> object, then make a weakref
Michael Chermside <[EMAIL PROTECTED]> writes:
> Adam Olsen:
>> I agree here. I think an executor approach is much better; kill the
>> object, then make a weakref callback do any further cleanups using
>> copies it made in advance.
I agree. Objects with finalizers with the semantics of __del__ ar
Barry Warsaw <[EMAIL PROTECTED]> writes:
> What worries me is the unpredictability of gc vs. refcounting. For
> some class of Python applications it's important that when an object
> is dereferenced it really goes away right then. I /like/ reference
> counting!
This can be solved by explicit fr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 19, 2006, at 10:42 AM, Marcin 'Qrczak' Kowalczyk wrote:
> Barry Warsaw <[EMAIL PROTECTED]> writes:
>
>> What worries me is the unpredictability of gc vs. refcounting. For
>> some class of Python applications it's important that when an object
Marcin 'Qrczak' Kowalczyk wrote:
> Reference counting is inefficient, doesn't by itself handle cycles,
> and is impractical to combine with threads which run in parallel. The
> general consensus of modern language implementations is that a tracing
> GC is the future.
How is reference counting inef
Barry Warsaw <[EMAIL PROTECTED]> writes:
> I don't see how that helps. I can remove all references to the
> object but I still have to wait until gc runs to free it. Can you
> explain your idea in more detail?
Objects which should be closed deterministically have the closing
action decoupled fr
Brian Quinlan <[EMAIL PROTECTED]> writes:
>> Reference counting is inefficient, doesn't by itself handle cycles,
>> and is impractical to combine with threads which run in parallel. The
>> general consensus of modern language implementations is that a tracing
>> GC is the future.
>
> How is refere
On 9/19/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> The following comments got me thinking:
> Raymond:
> > Statistics incontrovertibly prove that people who habitually
> > avoid __del__ lead happier lives and spend fewer hours in therapy ;-)
> Adam Olsen:
> > I agree here. I think an exec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 19, 2006, at 11:29 AM, Marcin 'Qrczak' Kowalczyk wrote:
> Barry Warsaw <[EMAIL PROTECTED]> writes:
>
>> I don't see how that helps. I can remove all references to the
>> object but I still have to wait until gc runs to free it. Can you
>> exp
Marcin 'Qrczak' Kowalczyk wrote:
> Brian Quinlan <[EMAIL PROTECTED]> writes:
>
>>> Reference counting is inefficient, doesn't by itself handle cycles,
>>> and is impractical to combine with threads which run in parallel. The
>>> general consensus of modern language implementations is that a tracin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 19, 2006, at 12:05 PM, Brian Quinlan wrote:
> Marcin 'Qrczak' Kowalczyk wrote:
>> Brian Quinlan <[EMAIL PROTECTED]> writes:
>>
Reference counting is inefficient, doesn't by itself handle cycles,
and is impractical to combine with thre
"Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> wrote:
>
> Brian Quinlan <[EMAIL PROTECTED]> writes:
>
> >> Reference counting is inefficient, doesn't by itself handle cycles,
> >> and is impractical to combine with threads which run in parallel. The
> >> general consensus of modern language imp
Barry Warsaw <[EMAIL PROTECTED]> writes:
> It's not external resources I'm concerned about, it's the physical
> memory consumed in process by objects which are unreachable but not
> reclaimed.
The rate of garbage collection depends on the rate of allocation.
While the objects are not freed in the
"Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> writes:
> It involves operations every time an object is merely passed around,
> as references to the object are created or destroyed.
And it does something when it frees an object. In some GCs there is
a cost associated with keeping an object alive
"Jim Jewett" <[EMAIL PROTECTED]> writes:
> I do think we should split __del__ into the (rare, problematic)
> general case and a "special-purpose" lightweight __close__ version
> that does a better job in the normal case.
A synchronous finalizer which doesn't keep object it refers to alive,
like P
Speaking on the speed of GC implementations, Marcin writes:
> I'm mostly speculating. It's hard to measure the difference between
> garbage collection schemes because most language runtimes are tied
> to a particular GC implementation, and thus you can't substitute a
> different GC leaving everythi
Paul Prescod schrieb:
> Even if I won't contribute code or even a design to the solution
> (because it isn't an area of expertise and I'm still working on
> encodings stuff) I think that there would be value in saying: "There's a
> big problem here and we intend to fix it in Python 3000."
This is
Nick Coghlan schrieb:
> I was thinking it would be easier to split out the Global Interpreter Lock
> and
> a per-interpreter Local Interpreter Lock, rather than trying to go to a full
> free-threading model. Anyone sharing other objects between interpreters would
> still need their own synchron
Marcin 'Qrczak' Kowalczyk schrieb:
> It doesn't move objects in memory, and thus free memory is fragmented.
That's true, but not a problem.
> Memory allocation can't just chop from from a single area of free memory.
That's not true. Python does it all the time. Allocation is in constant
time mos
Michael Chermside <[EMAIL PROTECTED]> wrote:
> Since we're apparently still in "propose wild ideas" mode for Py3K
> I'd like to propose that for Py3K we remove __del__. Not "fix" it,
> not "tweak" it, just remove it and perhaps add a note in the manual
> pointing people to the weakref module.
I
Greg Ewing <[EMAIL PROTECTED]> wrote:
>> * An easier C API would significantly benefit the language in terms
>> of more extensions being available and in terms of increased
>> reliability for those extensions. The current refcount scheme
>> results in pervasive refleak bugs and subsequent, interm
On 9/19/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Michael Chermside <[EMAIL PROTECTED]> wrote:
>
> > Since we're apparently still in "propose wild ideas" mode for Py3K
> > I'd like to propose that for Py3K we remove __del__. Not "fix" it,
> > not "tweak" it, just remove it and perhaps add a no
On Tue, 19 Sep 2006 23:42:43 +0200, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>Michael Chermside <[EMAIL PROTECTED]> wrote:
>
>> Since we're apparently still in "propose wild ideas" mode for Py3K
>> I'd like to propose that for Py3K we remove __del__. Not "fix" it,
>> not "tweak" it, just remove it
Marcin 'Qrczak' Kowalczyk wrote:
> Objects which should be closed deterministically have the closing
> action decoupled from the lifetime of the object.
That doesn't cover the case where the "closing" action
you want includes freeing the memory occupied by the
object. The game I mentioned earlier
Marcin 'Qrczak' Kowalczyk wrote:
> It doesn't move objects in memory, and thus free memory is fragmented.
That's not a feature of refcounting as such. With
sufficient indirection, moveable refcounted memory
blocks are possible (early Smalltalks worked that
way, I believe).
--
Greg
__
Michael Chermside wrote:
> Interestingly, one of the original goals of PyPy was to create a
> test bed in which it was easy to experiment and answer just this
> kind of question.
A worry about that is whether the architecture required to
allow pluggable GC implementations introduces inefficiencie
On 9/19/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Michael Chermside wrote:
>
> > Interestingly, one of the original goals of PyPy was to create a
> > test bed in which it was easy to experiment and answer just this
> > kind of question.
>
> A worry about that is whether the architecture required
Greg Ewing <[EMAIL PROTECTED]> writes:
>> It doesn't move objects in memory, and thus free memory is fragmented.
>
> That's not a feature of refcounting as such. With sufficient
> indirection, moveable refcounted memory blocks are possible
> (early Smalltalks worked that way, I believe).
Yes, but
Bob Ippolito wrote:
> There's no need to worry about that in the case of PyPy. Those kinds
> of choices are made way before runtime, so there's no required
> indirection.
Even so, we're talking about machine-generated code rather
than the sort of hand-crafting you need to get the best
out of some
On 9/19/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Nick Coghlan schrieb:
> > I was thinking it would be easier to split out the Global Interpreter Lock
> > and
> > a per-interpreter Local Interpreter Lock, rather than trying to go to a full
> > free-threading model. Anyone sharing other ob
Calvin Spealman schrieb:
>> The challenge with that is "global" (i.e. across-interpreter) objects.
>> There are several of these: the obvious singletons (None, True, False),
>> the non-obvious singletons ((), -2..100 or so), and the extension module
>> globals (types, and in particular exceptions).
Greg Ewing <[EMAIL PROTECTED]> writes:
> That doesn't cover the case where the "closing" action
> you want includes freeing the memory occupied by the
> object. The game I mentioned earlier is one of those --
> I don't need anything "closed", I just want the memory
Why do you want to free memory
32 matches
Mail list logo
