[IronPython] object lifecycle issues

[Dino Viehland]

Could this be issue 2?

class Real(object):
    def __new__(cls, *args, **kwargs):
        print 'real new'
        return object.__new__(Stub)
    #def __del__(self): pass     # uncomment me and this works as expected

class Stub(Real):
    def __del__(self):
        print "I've been finalized"

f = Real(1.0)
del f

import sys
if sys.platform == 'clr':
    import clr
    from System import GC
    for _ in range(4):
        GC.Collect()
        GC.WaitForPendingFinalizers()


> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of William Reade
> Sent: Monday, July 20, 2009 9:38 AM
> To: Discussion of IronPython
> Subject: [IronPython] object lifecycle issues
>
> Hi all
>
> I have two problems that are at least somewhat related:
>
> +++ Issue 1 (probably your bug):
>
> ---------------------------------------------------------------
> C:\dev\ironclad - Copy>ipy y.py
> real new
> stub new
> real init
> real del
>
> C:\dev\ironclad - Copy>python y.py
> real new
> stub new
> stub init
> real del
> ---------------------------------------------------------------
>
> I freely admit that the attached code is pretty weird, but I really do
> need to do stuff like this in Ironclad. The difference in behaviour may
> or may not be responsible for certain failing numpy/scipy tests -- I'm
> not sure how to tell -- but I'd enormously appreciate a fix.
>
> I'd report the issue on Codeplex, but trying to visit the issue tracker
> just leaves my browser spinning forever. Speaking of which: is there
> any alternative way of reporting bugs that doesn't make me feel as if
> I'm spamming the list with out-of-band noise? I'm pretty sure that a
> few bugs have just dropped off my stack in the last few months, just
> because I got tired of waiting for Codeplex to start working.
>
> +++ Issue 2 (almost certainly my bug):
>
> In a nearly identical* situation -- close enough that I can't say how
> it's actually different -- f will never get its __del__ method called
> (the object is destroyed -- a WeakReference to it knows it's dead --
> but the __del__ call never happens).
>
> For context: I have *very* similar classes, whose instances are
> constructed in exactly the weird way demonstrated in the attached file,
> and which work fine. The only difference between the cases that work
> and the cases that don't is that the broken cases multiply inherit from
> ipy types which wrap CLR types (int and float (and maybe str, although
> I haven't tested that one)), while the working cases have simple chains
> of single inheritance from user-defined types all the way up to object.
> However, the attached repro doesn't show my problem, so it's clearly
> not
> *just* to do with multiply inheriting from CLR types.
>
> Does anyone have any idea what I might be doing wrong? I know this is a
> vague request, but I'm running out of ideas, and I'd really appreciate
> some input from someone who understands precisely what all those ipy
> MetaFoo classes are doing.
>
> Cheers
> william
>
>
> * the attached file started life as an attempt to repro the __del__
> issue, and I incidentally noticed the __init__ issue.