On Sat, May 18, 2013 at 10:33 PM, Antoine Pitrou wrote:
> On Sat, 18 May 2013 16:22:55 +0200
> Armin Rigo wrote:
>> Hi Antoine,
>>
>> On Sat, May 18, 2013 at 3:45 PM, Antoine Pitrou wrote:
>> >> How is this done? I don't see a clear way to determine it by looking
>> >> only at the objects in th
On Sun, 2 Jun 2013 19:16:17 -0700
Benjamin Peterson wrote:
> 2013/5/18 Antoine Pitrou :
> > Calling finalizers only once is fine with me, but it would be a change
> > in behaviour; I don't know if it may break existing code.
>
> I agree with Armin that this is better behavior. (Mostly significant
On Sun, 2 Jun 2013 19:27:49 -0700
Benjamin Peterson wrote:
> 2013/5/18 Antoine Pitrou :
> >
> > Hello,
> >
> > I would like to submit the following PEP for discussion and evaluation.
>
> Will the API of the gc module be at all affected? I assume nothing
> will just be printed for DEBUG_UNCOLLECTA
2013/5/18 Antoine Pitrou :
>
> Hello,
>
> I would like to submit the following PEP for discussion and evaluation.
Will the API of the gc module be at all affected? I assume nothing
will just be printed for DEBUG_UNCOLLECTABLE. Maybe there should be a
way to discover when a cycle is resurrected?
2013/5/18 Antoine Pitrou :
> Calling finalizers only once is fine with me, but it would be a change
> in behaviour; I don't know if it may break existing code.
I agree with Armin that this is better behavior. (Mostly significantly
consistent with weakrefs.)
>
> (for example, say someone is using
On 5/18/2013 11:22 AM, Antoine Pitrou wrote:
On Sat, 18 May 2013 15:52:56 +0100
Richard Oudkerk wrote:
So even more contrived:
class Node:
def __init__(self, x):
self.x = x
self.next = None
def __del__(self):
print(sel
On Sat, 18 May 2013 15:52:56 +0100
Richard Oudkerk wrote:
> On 18/05/2013 3:18pm, Antoine Pitrou wrote:
> > It works fine:
> >
> > $ ./python sbt.py
> > <__main__.Node object at 0x7f3acbf8f400> <__main__.Node object at
> > 0x7f3acbf8f878>
> > <__main__.Node object at 0x7f3acbf8f878> <__main__.Nod
On 18/05/2013 3:18pm, Antoine Pitrou wrote:
It works fine:
$ ./python sbt.py
<__main__.Node object at 0x7f3acbf8f400> <__main__.Node object at
0x7f3acbf8f878>
<__main__.Node object at 0x7f3acbf8f878> <__main__.Node object at
0x7f3acbf8f400>
The reason is that, when you execute "del self.next"
On Sat, 18 May 2013 16:22:55 +0200
Armin Rigo wrote:
> Hi Antoine,
>
> On Sat, May 18, 2013 at 3:45 PM, Antoine Pitrou wrote:
> >> How is this done? I don't see a clear way to determine it by looking
> >> only at the objects in the CI, given that arbitrary modifications of
> >> the object graph
Hi Antoine,
On Sat, May 18, 2013 at 3:45 PM, Antoine Pitrou wrote:
>> How is this done? I don't see a clear way to determine it by looking
>> only at the objects in the CI, given that arbitrary modifications of
>> the object graph may have occurred.
>
> The same way a generation is traversed, bu
On Sat, 18 May 2013 14:56:38 +0100
Richard Oudkerk wrote:
> On 18/05/2013 9:59am, Antoine Pitrou wrote:
> > This PEP proposes to turn CI disposal into the following sequence (new
> > steps are in bold):
> >
> > 1. Weakrefs to CI objects are cleared, and their callbacks called. At
> > this poin
On Sat, May 18, 2013 at 6:47 AM, Antoine Pitrou wrote:
> On Sat, 18 May 2013 06:37:54 -0700
> Eli Bendersky wrote:
> > Great PEP, I would really like to see this happen as it defines much
> saner
> > semantics for finalization than what we currently have. One small
> question
> > below:
> >
> >
On 18/05/2013 9:59am, Antoine Pitrou wrote:
This PEP proposes to turn CI disposal into the following sequence (new
steps are in bold):
1. Weakrefs to CI objects are cleared, and their callbacks called. At
this point, the objects are still safe to use.
2. **The finalizers of all CI objects a
On Sat, 18 May 2013 06:37:54 -0700
Eli Bendersky wrote:
> Great PEP, I would really like to see this happen as it defines much saner
> semantics for finalization than what we currently have. One small question
> below:
>
>
> This PEP proposes to turn CI disposal into the following sequence (new
Hi Armin,
On Sat, 18 May 2013 15:24:08 +0200
Armin Rigo wrote:
> Hi Antoine,
>
> On Sat, May 18, 2013 at 10:59 AM, Antoine Pitrou wrote:
> > Cyclic isolate (CI)
> > A reference cycle in which no object is referenced from outside the
> > cycle *and* whose objects are still in a usable,
Great PEP, I would really like to see this happen as it defines much saner
semantics for finalization than what we currently have. One small question
below:
This PEP proposes to turn CI disposal into the following sequence (new
> steps are in bold):
>
> 1. Weakrefs to CI objects are cleared, and
Hi Antoine,
On Sat, May 18, 2013 at 10:59 AM, Antoine Pitrou wrote:
> Cyclic isolate (CI)
> A reference cycle in which no object is referenced from outside the
> cycle *and* whose objects are still in a usable, non-broken state:
> they can access each other from their respective final
On Sat, 18 May 2013 22:51:35 +1000
Nick Coghlan wrote:
> On Sat, May 18, 2013 at 9:46 PM, Antoine Pitrou wrote:
> > On Sat, 18 May 2013 21:05:48 +1000
> > Nick Coghlan wrote:
> >> On Sat, May 18, 2013 at 6:59 PM, Antoine Pitrou
> >> wrote:
> >> > Resurrection
> >> > The process by which a
On Sat, May 18, 2013 at 9:46 PM, Antoine Pitrou wrote:
> On Sat, 18 May 2013 21:05:48 +1000
> Nick Coghlan wrote:
>> On Sat, May 18, 2013 at 6:59 PM, Antoine Pitrou wrote:
>> > Resurrection
>> > The process by which a finalizer creates a new reference to an
>> > object in a CI. This can
On Sat, 18 May 2013 21:05:48 +1000
Nick Coghlan wrote:
> On Sat, May 18, 2013 at 6:59 PM, Antoine Pitrou wrote:
> > Resurrection
> > The process by which a finalizer creates a new reference to an
> > object in a CI. This can happen as a quirky but supported
> > side-effect of ``__del
On Sat, May 18, 2013 at 6:59 PM, Antoine Pitrou wrote:
> Resurrection
> The process by which a finalizer creates a new reference to an
> object in a CI. This can happen as a quirky but supported
> side-effect of ``__del__`` methods.
I really like the PEP overall, but could we at leas
Hello,
I would like to submit the following PEP for discussion and evaluation.
Regards
Antoine.
PEP: 442
Title: Safe object finalization
Version: $Revision$
Last-Modified: $Date$
Author: Antoine Pitrou
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2013-05-18
Python-V
22 matches
Mail list logo
