Message7434

> "I had submitted this bug because some of the SQLAlchemy test cases use getrefcount."

OK.

That could give rise to problems.

The "problem" with cpythons refcounting GC is that it gives very precise guarantees about when an object is destroyed, i.e. when its __del__ method is called.

It is not possible to support these guarantees on jython, given the nature of Java GC.

Consider the following code, run on both python and jython.

C:\>python
Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class o:
...     def __init__(self):
...         print "Hello"
...     def __del__(self):
...         print "Goodbye"
...
>>> my_o = o()
Hello
>>> del my_o
Goodbye
>>> ^Z
C:\>

C:\>jython
Jython 2.7a0+ (, Mar 31 2012, 21:43:20)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_29
Type "help", "copyright", "credits" or "license" for more information.
>>> class o:
...     def __init__(self):
...         print "Hello"
...     def __del__(self):
...         print "Goodbye"
...
>>> my_o = o()
Hello
>>> del my_o
>>>^D
C:\>

Note that the __del__ method may not even be run on jython.

This may not be a problem for you in your work with SQLAlchemy. But I thought it worth pointing it out.

And it is arguable that cpython code that depends on the object-lifecycle guarantees cpython's refcounting GC is not portable.

For example, pypy has a wide range of GC options available, where the cpython guarantees will not hold.

http://doc.pypy.org/en/latest/garbage_collection.html