On Sun, 2 Jun 2013 19:27:49 -0700
Benjamin Peterson benja...@python.org wrote:
2013/5/18 Antoine Pitrou solip...@pitrou.net:
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
On Sat, May 18, 2013 at 10:33 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 18 May 2013 16:22:55 +0200
Armin Rigo ar...@tunes.org wrote:
Hi Antoine,
On Sat, May 18, 2013 at 3:45 PM, Antoine Pitrou solip...@pitrou.net wrote:
How is this done? I don't see a clear way to determine it
2013/5/18 Antoine Pitrou solip...@pitrou.net:
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
2013/5/18 Antoine Pitrou solip...@pitrou.net:
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
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 solip...@pitrou.net
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created:
On Sat, May 18, 2013 at 6:59 PM, Antoine Pitrou solip...@pitrou.net 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
On Sat, 18 May 2013 21:05:48 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sat, May 18, 2013 at 6:59 PM, Antoine Pitrou solip...@pitrou.net 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
On Sat, May 18, 2013 at 9:46 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 18 May 2013 21:05:48 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sat, May 18, 2013 at 6:59 PM, Antoine Pitrou solip...@pitrou.net wrote:
Resurrection
The process by which a finalizer creates a new
On Sat, 18 May 2013 22:51:35 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sat, May 18, 2013 at 9:46 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 18 May 2013 21:05:48 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sat, May 18, 2013 at 6:59 PM, Antoine Pitrou solip...@pitrou.net
Hi Antoine,
On Sat, May 18, 2013 at 10:59 AM, Antoine Pitrou solip...@pitrou.net 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
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 Armin,
On Sat, 18 May 2013 15:24:08 +0200
Armin Rigo ar...@tunes.org wrote:
Hi Antoine,
On Sat, May 18, 2013 at 10:59 AM, Antoine Pitrou solip...@pitrou.net wrote:
Cyclic isolate (CI)
A reference cycle in which no object is referenced from outside the
cycle *and* whose
On Sat, 18 May 2013 06:37:54 -0700
Eli Bendersky eli...@gmail.com 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
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
On Sat, May 18, 2013 at 6:47 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 18 May 2013 06:37:54 -0700
Eli Bendersky eli...@gmail.com 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
On Sat, 18 May 2013 14:56:38 +0100
Richard Oudkerk shibt...@gmail.com 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
Hi Antoine,
On Sat, May 18, 2013 at 3:45 PM, Antoine Pitrou solip...@pitrou.net 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
On Sat, 18 May 2013 16:22:55 +0200
Armin Rigo ar...@tunes.org wrote:
Hi Antoine,
On Sat, May 18, 2013 at 3:45 PM, Antoine Pitrou solip...@pitrou.net 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
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, this
On Sat, 18 May 2013 15:52:56 +0100
Richard Oudkerk shibt...@gmail.com 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__.Node
On 5/18/2013 11:22 AM, Antoine Pitrou wrote:
On Sat, 18 May 2013 15:52:56 +0100
Richard Oudkerk shibt...@gmail.com wrote:
So even more contrived:
class Node:
def __init__(self, x):
self.x = x
self.next = None
def __del__(self):
21 matches
Mail list logo
