A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-October/009908.html below:

[Python-Dev] test_minidom non-failure failure? (take 2)

[Python-Dev] test_minidom non-failure failure? (take 2) [Python-Dev] test_minidom non-failure failure? (take 2)Neil Schemenauer nas@arctrix.com
Thu, 12 Oct 2000 06:43:09 -0700
On Thu, Oct 12, 2000 at 04:26:49PM -0500, Guido van Rossum wrote:
> > This is a policy decision.  Is it okay for the test suite to
> > create garbage that is not collectable by reference counting?
> 
> I don't see why that should be forbidden.  After all some of the code
> we test has such leaks -- we haven't declared those absolute bugs.

Again, "-l" should probably not be a default.  I don't know who
added it to TESTOPTS but it wasn't me.

> Can you give an example of how such garbage can be created?

Look at test_gc.  Here is an example:

    class Foo:
        def __del__(self):
            pass
    foo = Foo()
    foo.foo = foo
    del foo

Theoretically this structure could be collected without problem
but the GC is too simple minded to realize that there is only one
finalizer involved.  Here's a better example:

    foo = Foo()
    bar = Foo()
    foo.bar = bar
    bar.foo = foo
    del foo, bar

The GC cannot safely break this cycle so it punts and adds the
instance objects involved to gc.garbage and forgets about it.

  Neil



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4