Steven Bethard wrote:
> You already don't need to list the attributes from the base classes.
> The __finalattrs__ are converted into class level descriptors, so if
> class D inherits from class C, it has the __finalattrs__ descriptors
> for both classes.
That's fine, then.
--
Greg
__
On 5/12/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
>
> > Yep. The 'self' passed to __finalize__ is still an instance of the
> > same class (e.g. BufferedWriter or MyWriter). So inheritance works
> > normally:
>
> However, if the overridden method uses any attributes
> not men
Steven Bethard wrote:
> Yep. The 'self' passed to __finalize__ is still an instance of the
> same class (e.g. BufferedWriter or MyWriter). So inheritance works
> normally:
However, if the overridden method uses any attributes
not mentioned in the original __finalattrs__, they
will need to be adde
On 5/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > And here's a version that doesn't lose updates to the finalizer attributes:
> >
> > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519635
> >
> > It replaces enable_final
On 5/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> And here's a version that doesn't lose updates to the finalizer attributes:
>
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519635
>
> It replaces enable_finalizer() with a class attribute __finalattrs__.
> >From __finalize__,
On 5/7/07, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> FWIW and in light of the thread on removing __del__ from the language, I
> just posted Yet Another Recipe for automatic finalization:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519621
>
> It allows writing a finalizer as a single
FWIW and in light of the thread on removing __del__ from the language, I
just posted Yet Another Recipe for automatic finalization:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519621
It allows writing a finalizer as a single __finalize__ method, at the
cost of explicitly calling an en
Giovanni Bajo wrote:
> What I really meant was:
>
>self.__wr = weakref.ref(self, ...)
Okay, that looks better. But I'm not sure what will
happen if the holder becomes part of a cycle. If the
GC picks the holder as the object to clear to break
the cycle, then the weakref will be deallocated
be
On 01/05/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
PEP: Eliminating __del__
+1
--
Cheers,
Hasan Diwan <[EMAIL PROTECTED]>
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
Martin v. Löwis wrote:
> Procedurally, there is a problem that this still isn't an
> officially-posted PEP, even though it's already several days
> past the deadline. OTOH, it's listed in the PEP parade. Still,
> I would like to see a posted PEP rather sooner than later.
> Defending the deadline wi
> Can I please press the button for a few days until I can offer a
> useful starting point.
Socially, this is the point of the PEP process in the first place: the
PEP author is supposed to collect community feedback in the PEP, and
address it as necessary. People won't stop discussing if the PE
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
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
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
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 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
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/
Raymond Hettinger wrote:
> Can I please press the button for a few days until I can offer
> a useful starting point.
Before you go any further, the important thing to take
from the thread so far is that you mustn't keep the
whole contents of the object's __dict__ alive via
the callback.
--
Gre
> If it really has to be done this way, I think the whole PEP is doomed.
This thread is getting way ahead of me and starting to self-destruct before
I've had a chance to put together a concrete proposal and scan existing code
for use cases.
Can I please press the button for a few days until I
On 5/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/4/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 5/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > Hm, a thought just occurred to me. Why not arrange for object.__new__
> > > to call [the moral equivalent of] weakref.cleanu
On 5/4/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 5/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 5/4/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > An encapsulating function should be added to the weakref module
> > > so that Guido's example could be written as:
> > >
>
On 5/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/4/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > An encapsulating function should be added to the weakref module
> > so that Guido's example could be written as:
> >
> > class BufferedWriter:
> >
> > def __init__(self, raw):
> >
On 5/4/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> An encapsulating function should be added to the weakref module
> so that Guido's example could be written as:
>
> class BufferedWriter:
>
> def __init__(self, raw):
> self.raw = raw
> self.buffer = ""
> weakref.cleanup(self, l
On May 4, 2007, at 10:33 AM, Giovanni Bajo wrote:
> On 5/4/2007 4:21 PM, Michael Bayer wrote:
>
>>>
>> why not encapsulate the "proper" weakref-based approach in an easy-
>> to-use method such as "__close__()" ? that way nobody has to
>> guess how to follow this pattern.
>
> Because the idea
[Michael Bayer]
> why not encapsulate the "proper" weakref-based approach in an easy-to-
> use method such as "__close__()" ? that way nobody has to guess how
> to follow this pattern.
An encapsulating function should be added to the weakref module
so that Guido's example could be written as:
On May 4, 2007, at 1:12 AM, Raymond Hettinger wrote:
> From: "Greg Ewing" <[EMAIL PROTECTED]>
>> It has nothing to do with cyclic GC. The point is that
>> if the refcount of a weak reference drops to zero before
>> that of the object being weakly referenced, the weak
>> reference object itself is
From: "Greg Ewing" <[EMAIL PROTECTED]>
> It has nothing to do with cyclic GC. The point is that
> if the refcount of a weak reference drops to zero before
> that of the object being weakly referenced, the weak
> reference object itself is deallocated and its callback
> is *not* called. So having th
In all the threads about this PEP I still haven't seen a single
example of how to write a finalizer.
Let's take a specific example of a file object (this occurs in io.py
in the p3yk branch). When a write buffer is GC'ed it must be flushed.
The current way of writing this is simple:
class Buffered
Giovanni Bajo wrote:
> On 01/05/2007 18.09, Phillip J. Eby wrote:
> > That means that if 'self' in your example above is collected, then
> > the weakref no longer exists, so the closedown won't be called.
>
> Yes, but as far as I understand it, the GC does special care to ensure that
> the callb
On 01/05/2007 18.09, Phillip J. Eby wrote:
>> The alternative is to code the automatic finalization steps using
>> weakref callbacks. For those used to using __del__, it takes a little
>> while to learn the idiom but essentially the technique is hold a proxy
>> or ref with a callback to a boundme
At 12:31 AM 5/1/2007 -0700, Raymond Hettinger wrote:
>The alternative is to code the automatic finalization steps using
>weakref callbacks. For those used to using __del__, it takes a little
>while to learn the idiom but essentially the technique is hold a proxy
>or ref with a callback to a boundm
On 5/1/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> The alternative is to code the automatic finalization steps using
> weakref callbacks. For those used to using __del__, it takes a little
> while to learn the idiom but essentially the technique is hold a proxy
> or ref with a callback to a
On 01/05/2007 9.31, Raymond Hettinger wrote:
> PEP: Eliminating __del__
*sigh* I'm still -1, but I won't revive the discussion of course.
I would still like if the PEP listed the alternative me and others were
proposing, that is changing the semantic of __del__ (or dropping __del__ in
favor o
> Historically, __del__ has been one of the more error-laden dark corners
> of the language. From an implementation point of view, it has
> proven to be a thorny maintenance problem that grew almost beyond
> the range of human comprehension once garbage collection was introduced.
+1
Martin
_
PEP: Eliminating __del__
Motivation
Historically, __del__ has been one of the more error-laden dark corners
of the language. From an implementation point of view, it has
proven to be a thorny maintenance problem that grew almost beyond
the range of human comprehension once garbage collection wa
35 matches
Mail list logo
