Giovanni Bajo wrote:
> It would require some effort to make weakref finalizers *barely* as usable
> as __del__, and will absolutely not solve the problem per-se: the user will
> still have to pay attention and understand the hoops (different kind of
> hoops, but still hoops). So, why do we not spen
This was bit too brief I think...
Ron Adam wrote:
> How about...? (This isn't an area I'm real familiar with.)
>
>
> Replace __del__ with:
>
> a __final__ method and a __finalized__ flag. (or other equivalent names)
The __final__ method would need to be explicitly called, and the __fina
Giovanni Bajo wrote:
> I assert that they hide bugs much better than
> __del__ does (it's pretty easy to find an offending __del__ by looking at
> gc.garbage,
It should be feasible to modify the cyclic GC to
detect groups of objects that are only being kept
alive by references from the finalizer l
"Tim Peters" <[EMAIL PROTECTED]> writes:
> Read Modules/gc_weakref.txt for the gory details.
"It's a feature of Python's weakrefs too that when a weakref goes
away, the callback (if any) associated with it is thrown away too,
unexecuted."
I disagree with this choice. Doesn't it prevent weakrefs
Tim Peters wrote:
> [Giovanni Bajo]
>> Raymond, there is one thing I don't understand in your line of
>> reasoning. You say that you prefer explicit finalization, but that
>> implicit finalization still needs to be supported. And for that,
>> you'd rather drop __del__ and use weakrefs. But why? Yo
Nick Coghlan wrote:
>> Raymond, there is one thing I don't understand in your line of
>> reasoning. You say that you prefer explicit finalization, but that
>> implicit finalization still needs to be supported. And for that,
>> you'd rather drop __del__ and use weakrefs. But why? You say that
>> __
On 9/26/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Giovanni Bajo wrote:
> > I assert that they hide bugs much better than
> > __del__ does (it's pretty easy to find an offending __del__ by looking at
> > gc.garbage,
> It should be feasible to modify the cyclic GC to
> detect groups of objects tha
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
> Guido was proposing a solution with __del__ and CT, which
> approximately worked this way:
>
> - When a CT is detected, any __del__ method is invoked once per
> instance, in random order.
This means that __del__ may attempt to use an object which has
Jim Jewett wrote:
>>> You say that __del__ is harardous, but I can't see how
>>> weakrefs are less hazardous. As an implicit finalization method,
>>> they live on the fragile assumption that the callback won't hold a
>>> reference to the object:
>
>> Nope, not so.
>
> I think you read "live" as
On 9/26/06, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> "Giovanni Bajo" <[EMAIL PROTECTED]> writes:
> > Guido was proposing a solution with __del__ and CT, which
> > approximately worked this way:
> > - When a CT is detected, any __del__ method is invoked once per
> > instance, in rand
On 9/26/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Giovanni Bajo]
> > You say that __del__ is harardous, but I can't see how
> > weakrefs are less hazardous. As an implicit finalization method, they live
> > on
> > the fragile assumption that the callback won't hold a reference to the
> > objec
Giovanni Bajo wrote:
> Since we are discussing Py3k here, I believe it is the right time to revive
> this discussion. The __close__ proposal I'm backing (sumed up in this mail:
> http://mail.python.org/pipermail/python-3000/2006-September/003892.html) is
> pretty similar to how Guido was proposing
Giovanni Bajo wrote:
> Raymond Hettinger wrote:
>
>> In short, __del__ should disappear not because it is useless but
>> because
>> it is hazardous. The consenting adults philosophy means that we don't
>> put-up artificial barriers to intentional hacks, but it does not mean
>> that we bait the ho
Raymond Hettinger wrote:
> In short, __del__ should disappear not because it is useless but
> because
> it is hazardous. The consenting adults philosophy means that we don't
> put-up artificial barriers to intentional hacks, but it does not mean
> that we bait the hook and leave error-prone traps
[Giovanni Bajo]
> Raymond, there is one thing I don't understand in your line of reasoning. You
> say that you prefer explicit finalization, but that implicit finalization
> still
> needs to be supported. And for that, you'd rather drop __del__ and use
> weakrefs. But why? You say that __del__ is
Paul Prescod schrieb:
> There is at least one big difference between surrogate pairs and
> decomposed characters. The user can typically normalize away
> decompositions. How do you normalize away decompositions in a language
> that only supports 16-bit representations?
I don't see the problem: Yo
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> It is somewhat tricky to implement a normalization algorithm in
> UTF-16, since you must combine surrogate pairs first in order to
> find out what the canonical decomposition of the code point is;
> but it's just more code, and no problem in principl
Fredrik Lundh schrieb:
>> I believe it would noticeably simplify the implementation if there is
> > only a single internal representation.
>
> and I, wearing my string algorithm implementor hat, tend to disagree
> with that. writing source code that can be compiled into efficient code
> for mu
I misspoke. I meant to ask: "How do you normalize away surrogate pairs in UTF-16?" It was a rhetorical question. The point was just that decomposed characters can be handled by implicit or explicit normalization. Surrogate pairs can only be similarly normalized away if your model allows you to repr
Marcin 'Qrczak' Kowalczyk wrote:
> "It's a feature of Python's weakrefs too that when a weakref goes
> away, the callback (if any) associated with it is thrown away too,
> unexecuted."
>
> I disagree with this choice. Doesn't it prevent weakrefs to be used as
> finalizers?
No, it's quite possibl
Jim Jewett wrote:
> Given this complexity, what advantage would it have over __del__, let
> alone __close__?
It wouldn't constitute an attractive nuisance, since
it would force you to think about which pieces of
information the finalizer really needs. This is
something you need to do anyway if yo
Giovanni Bajo wrote:
> Is that easier or harder to detect such a cycle, compared to accidentally
> adding a reference to self (through implicit nested scopes, or bound
> methods) in the finalizer callback?
I would put a notice in the docs strongly recommending that
only global functions be regist
Nick Coghlan wrote:
> the weakref (WR) and the callback (CB) are in a
> cycle with each other, so even after CB is invoked and removes WR from the
> global list of finalizers, the two objects won't go away until the next GC
> collection cycle.
The CB can drop its reference to the WR when it's i
Greg Ewing wrote:
>>> # Use closure to get at weakref to allow direct invocation
>>> # This creates a cycle, so this approach relies on cyclic GC
>>> # to clean up the finalizer objects!
>
> This implementation is broken. There's no need
> to create any such cycle.
I know,
24 matches
Mail list logo
