On May 14, 2013, at 9:39 AM, Gregory P. Smith wrote:
> Bad: doctests.
I'm hoping that core developers don't get caught-up in the "doctests are bad
meme".
Instead, we should be clear about their primary purpose which is to test
the examples given in docstrings. In many cases, there is a gre
On Sat, May 18, 2013 at 10:27 PM, Raymond Hettinger
wrote:
> BTW, I'm +1 on the idea for ordering keyword-args. It makes
> it easier to debug if the arguments show-up in the order they
> were created. AFAICT, no purpose is served by scrambling them
> (which is exacerbated by the new randomized h
On May 15, 2013, at 4:32 AM, Christian Tismer wrote:
> What is the current status of this discussion?
> I'd like to know whether it is a considered alternative implementation.
As far as I can tell, I'm the only one working on it (and a bit slowly at that).
My plan is to implement it for frozens
18.05.13 23:00, Serhiy Storchaka написав(ла):
18.05.13 19:37, richard.oudkerk написав(ла):
http://hg.python.org/cpython/rev/0648e7fe7a72
changeset: 83829:0648e7fe7a72
user:Richard Oudkerk
date:Sat May 18 17:35:19 2013 +0100
summary:
Use PY_FORMAT_SIZE_T because Visual Studi
18.05.13 19:37, richard.oudkerk написав(ла):
http://hg.python.org/cpython/rev/0648e7fe7a72
changeset: 83829:0648e7fe7a72
user:Richard Oudkerk
date:Sat May 18 17:35:19 2013 +0100
summary:
Use PY_FORMAT_SIZE_T because Visual Studio does not understand %zd format.
See also DE
18.05.13 10:06, raymond.hettinger написав(ла):
http://hg.python.org/cpython/rev/1b760f926846
changeset: 83823:1b760f926846
user:Raymond Hettinger
date:Sat May 18 00:05:20 2013 -0700
summary:
Undo the deprecation of _asdict().
Why?
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
I've had a quick look with grep -R HAVE_ * | egrep '[.]c:'.
Modules/posixmodule.c has HAVE_UTIME_H and it might be standard libc on all
posix platforms.
Objects/obmalloc.c has HAVE_MMAP… but I guess that's fine given other platforms
might not have such facility.
Depending on the granularity (
24 matches
Mail list logo
