Issue1175

classification
Title: gc.disable() throws "NotImplementedError: can't disable Java GC"
Type: behaviour Severity: minor
Components: Library Versions: 2.5b0
Milestone:
process
Status: closed Resolution: invalid
Dependencies: Superseder:
Assigned To: Nosy List: colinhevans, otmarhumbel, zyasoft
Priority: Keywords:

Created on 2008-11-20.01:28:31 by colinhevans, last changed 2008-11-21.21:02:00 by zyasoft.

Messages
msg3790 (view) Author: Colin Evans (colinhevans) Date: 2008-11-20.01:29:47
gc.disable() throws "NotImplementedError: can't disable Java GC".  Can
it just ignore the call instead in order to maintain compatibility?  

Here's the output when run on PyBench:

-------------------------------------------------------------------------------
PYBENCH 2.0
-------------------------------------------------------------------------------
* using Python 2.5b0
Traceback (most recent call last):
  File "./pybench.py", line 938, in <module>
    PyBenchCmdline()
  File "/u/colin/pybench/CommandLine.py", line 346, in __init__
    rc = self.main()
  File "./pybench.py", line 842, in main
    gc.disable()
NotImplementedError: can't disable Java GC
msg3791 (view) Author: Oti Humbel (otmarhumbel) Date: 2008-11-20.09:15:20
Colin, 
AFAIK there is no way of disabling the garbage collector in Java.
This is documented in the docstring of gc:

>>> import gc
>>> print gc.__doc__
This module provides access to the garbage collector.

enable() -- Enable automatic garbage collection (does nothing).
isenabled() -- Returns True because Java garbage collection cannot be
disabled.
collect() -- Trigger a Java garbage collection (potentially expensive).
get_debug() -- Get debugging flags (returns 0).

Other functions raise NotImplementedError because they do not apply to Java.

>>>
msg3800 (view) Author: Jim Baker (zyasoft) Date: 2008-11-21.21:01:59
gc.disable() is also used in Jython's Lib:
 * timeit.py - need to fix
 * subprocess.py - apparently this path is not being exercised by
test_subprocess.py, or perhaps it never gets used at all!

In general, we should just fix the offending code, not our gc wrapper,
so I agree in keeping it closed. If we were to have some sort of
compatibility shim, it needs to be of larger scope than just for gc.
History
Date User Action Args
2008-11-21 21:02:00zyasoftsetnosy: + zyasoft
messages: + msg3800
2008-11-20 09:45:38otmarhumbelsetstatus: open -> closed
resolution: invalid
2008-11-20 09:15:21otmarhumbelsetnosy: + otmarhumbel
messages: + msg3791
2008-11-20 01:29:48colinhevanssetmessages: + msg3790
2008-11-20 01:28:31colinhevanscreate