Issue1960
Created on 2012-08-18.17:05:58 by adorsk, last changed 2012-08-28.19:01:28 by amak.
Messages | |||
---|---|---|---|
msg7413 (view) | Author: Alex the Jython User (adorsk) | Date: 2012-08-18.17:05:57 | |
The 'sys' module appears to be missing the 'getrefcount' method. ==== Example ==== === code === import sys a = [1,2,3] sys.getrefcount(a) === result === AttributeError: '<reflected field public org.python.core.PyObject o' object has no attribute 'getrefcount' |
|||
msg7424 (view) | Author: Alan Kennedy (amak) | Date: 2012-08-25.21:05:40 | |
sys.getrefcount is not meaningful on jython, only on cpython. cpython uses reference-counting for garbage collection. Read more here http://en.wikipedia.org/wiki/Reference_counting Jython, because it runs on Java Virtual Machines, uses Java Garbage Collection, which may use one of several different garbage collection mechanisms, mostly much more sophisticated than relatively basic ref-counting algorithms. Read more here http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html So basically sys.getrefcount would have no meaning on java/jython, and there is no way to implement it. I'm going to close this bug as "invalid". If you think that you need to use the sys.getrefcount method, please send an email, describing your use-case, to the jython-users mailing list. |
|||
msg7430 (view) | Author: Alex the Jython User (adorsk) | Date: 2012-08-28.12:14:57 | |
Roger that, thanks for the detailed explanation. I had submitted this bug because some of the SQLAlchemy test cases use getrefcount. But based on your explanation it sounds like it makes more sense to modify the SQLAlchemy code instead to check for whether it's running in a jython environment. No need for any further action on this. Thanks in general for the great work on Jython. |
|||
msg7434 (view) | Author: Alan Kennedy (amak) | Date: 2012-08-28.19:01:28 | |
> "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 |
History | |||
---|---|---|---|
Date | User | Action | Args |
2012-08-28 19:01:28 | amak | set | messages: + msg7434 |
2012-08-28 12:14:57 | adorsk | set | messages: + msg7430 |
2012-08-25 21:05:42 | amak | set | status: open -> closed assignee: amak resolution: invalid messages: + msg7424 nosy: + amak |
2012-08-18 17:05:58 | adorsk | create |
Supported by Python Software Foundation,
Powered by Roundup